Shubh: I think so too, this virtualized thing is starting to be just too much trouble.
If possible, we can take a page from the musicbrainz dropdown and show first the 20 or so often-used languages (frequency = 2) and then below the 400-ish less used languages (frequency = 1).
Added to that, since we have the option to do it, I would keep the dropdown searchable (with an language search endpoint) to give users access to the 7000+ remaining languages with frequency = 0
So to be clear: I propose we load the 425 languages with frequency >= 1, showing the 21 more common languages separately in the same dropdown like so: https://usercontent.irccloud-cdn.com/file/xY2Wf...
The rest can be accessed with an async search endpoint
Shubh
i think we don't even need a end point for this, we can just asynchronously load languages on client using promises
monkey
load from where?
Shubh
load from client itself since we will have access to all languages we can just filter languages on the fly
monkey
I guess we can try that. On the one hand we still load all the languages which takes some space it the props, but on the other hand there's no need for a new endpoint and it will work faster
Shubh
if you like i can quicky made a PR for this or add it existing refactor PR
CatQuest
please tell me when dne so i can test it
:D
monkey
New PR please Shubh :)
CatQuest
:O thunderstorm here today ⛈
Shubh
monkey: can we have current unified form on test.bb?
monkey
Shubh: Sure I can deploy it, but do we not need to merge #847 and rebase first?
Shubh
yep indeed
monkey
Shubh: I've got the language select up on test, which works great. I'll merge it now and move on to the multi-entity POST route PR next.
One thing I wanted to note: we appear to still have a similar slowdown issue when selecting a language/clearing the dropdown (scrolling and searching work very fast, nice job :) ).
Not a huge issue but profiling confirms it is adding documents to the js-search index.
You had done some work to memoize the component, but I think we must be missing something if the documents are reindexed on state change.
Not going to block this PR, but if you're up for it, perhaps something you could resolve later on
Now this is turning into a train of thought :steam_locomotive: :D
Should the `areEqual` method here only check the `options` prop rather than all the props? Because if the selected value changed the props won't be equal, which in turn means no memoization…
But we do want the component to re-render when the language state changes, since we display the selected option in the dropdown. Not sure memoization will solve our issue for this case
P.S: just updated #850 and going to deploy it now to test.BB
just a heads up: if I am offline (catquest) tomorrow (because the thundestorm is huge tonight and my connection company is shit on usual days anyway) you can talk to KassOtsimine instead