LB-1727: Filters for link listens page

[granth23]

Problem

LB1727: Filters for link listens page

Solution

FIlter.webm

Filtering functionality added

Action

• Let me know if any additional details or corrections are required.
• If the changes look good, kindly proceed with merging the PR.

[anshg1214]

The PR Looks good. However you can perform cleanup by using bootstrap classes.

[anshg1214]

One final change, and we're good to go.

[MonkeyDo]

Nice work so far, it's working quite nicely!
I think searching by entity type was the right choice, otherwise it would get quite confusing I think.

Currently missing:

• a button to clear the search (currently emptying the search bar you can't click on the search button)
• another state variable to hold the original unlinkedListensProps, which is what we should use as the searchable list. If you link a track, it is removed from the list of options (see for example in the openMultiTrackMappingModal function). We should be able to hold state of the modified list while also beign able to filter it.
• a "no results" message to show users

[MonkeyDo]

Currently I think this code path will never be hit, because the submit button will be disasbled if there are less that X characters.
However that also means we probably need a "clear search" button or a system that will detect char length in the textarea onChange callback, and set the unfiltered list.
Not sure what is the best way to handle this, what are your thoughts? clear search button, or always-enabled submit button?

[granth23]

The last commit didn't have the below code segment
if (!searchQuery) { setUnlinkedListens(unlinkedListensProps); return; }
So that has been catered to already, a clear search button leading to the unfiltered Link Listens is a must so will make the changes.

[granth23]

I’m a bit confused about the second point you mentioned. From my perspective, if a user filters and then links a track, the next search should display only unlinked listens that are still unlinked. Why should the original list be used as the searchable list, considering it might include tracks that have already been linked? Please let me know if I’m misunderstanding something.

[MonkeyDo]

I’m a bit confused about the second point you mentioned. From my perspective, if a user filters and then links a track, the next search should display only unlinked listens that are still unlinked. Why should the original list be used as the searchable list, considering it might include tracks that have already been linked? Please let me know if I’m misunderstanding something.

Ah, well precisely! You understand the issue we would encounter, but that is how the current code behaves.
My suggestion is meant to fix this issue.

This line in handleReset in your current code resets the list to the original one passed in props, which is going to contain tracks we might have just linked:
setUnlinkedListens(unlinkedListensProps); // Reset to the original list

To resolve that issue, I think we need to store a modifiable list separately, originally equal to unlinkedListensProps, which we modify as we link listens and then use as the reset value.

EDIT: Another issue is that currently, if you filter results, you can't change the search query and do another search, because the initial filtered list is used as the base for filtering the second time.
Try searching for a word you know is in use for a track, then without resetting, try searching for another word you know is in another track.

[MonkeyDo]

Deployed to https://test.listenbrainz.org/settings/link-listens/ for further testing

[anshg1214]

LGTM