Feature/dropdown improved

[Meesch]

Fetches ALL the options for the multiselect dropdown filter (up to a maximum of 10,000). It fetches all values for a filter only when that specific filter is openened (using the onPanelOpen hook in the template), or when that filter is changed. The full list is not fetched when another filter is changed, as any newly fetched data would only become relevant when the user wants to select new values on which to filter.

For example, take a corpus with 10,000 speakers, but the corpus definition has defined an option_count=10 for speakers, and two chambers:

• I open the Speaker filter, I get 10,000 values for that filter.
• I select one speaker to filter on, I get the 10,000 values again for Speaker and mark the selected one.
  • in the background, all other dropdown filters get as many values as are defined in the corpus definition
• I close the Speaker filter
• I open the Chamber filter, I send a request for 10,000 values, I get back two values.
• I select a chamber to filter on, I send another request for 10,000 values, I get back the same two again.
  • In the background, the speaker filter makes a request for 10 speakers (not 10,000)

I hope this explanation makes it clear that the intended behaviour is: when a user clicks the filter, get all values, but do not get all values when the user is busy with another filter.

[lukavdplas]

I like that you ended up with a pretty simple solution, nice. There are still a few comment, see below.

Also, you still have the problem that users may load a URL with an arbitrary value for the filter. This is an issue if the filter is not pre-fetching values - the value won't be shown properly.

[lukavdplas]

Why set this?

[Meesch]

[virtualscroll]: necessary to virtualscroll
[virtualScrollItemSize]: obligatory field, is overwritten in CSS (should we make that clear somewhere?)
[lazy]: can be and will be removed, good catch
[maxSelectedLabels]: this ensures that if more than 1 label (filter) is selected, it shows '2 items selected' instead of the labelnames.

[lukavdplas]

Not sure if lazy adds anything here. (As I mentioned, the function of this is a bit unclear.)

[lukavdplas]

Right now, every filter will make a new query request when the panel is opened, but this results in unnecessary extra requests for fields with only a few values - it's just fetching the data twice. Then for filters like speaker, it's the initial request that isn't necessary, since the list is not shown before this point.

My suggestion would be to use the option_count for this; if the option count is modest, you can eagerly fetch the options, the way we do currently. If it's very high, you delay the request until the user has at least opened the panel once. After that, you can refetch as normal.

(In the future, we might transition the option count to a boolean.)

[Meesch]

Oops I added a feature. Users can now see the number of unique values per (keyword) field on the corpus info page.