[BUU] Producers selects are to be populated on focus

[cyrillefr]

What? Why?

• Closes [BUU] Optimisation: long select lists repeated #12482

When visiting page admin/products (in V3 mode), each select is populated via the classical Rails way.

But each select carries the same data, which can be some overload for the producers selects that may carry a lot of data.
My solution is instead to put the producers data once in a html element template.
Each select is only populated with its default.
Then, on focus, it is populated.
Therefore, no more copying 10 times the same options for the 10 selects.
Also, it is now the browser job to populate the focused select.
One group of data is written on the page instead of 10, which reduces the server work.

I have created for that a Stimulus controller that inherit from tom-select, and not a StimulusReflex one.

What should we test?

• In V3 toggled mode, as an admin or producer
• Visit admin/products
• There should be no change with the current display of selects.
• The same behaviour should be seen: change one item and page should notice.
• Changing a producer for a product should work as expected.
• From 10 items or more, a search input must be visible, but not under 10 or 10

Release notes

Changelog Category (reviewers may add a label for the release notes):

• User facing changes
• API changes (V0, V1, DFC or Webhook)
• Technical changes only
• Feature toggled

The title of the pull request will be included in the release notes.

Dependencies

Documentation updates

[rioug]

Nice approach ! I just have one suggestion to make it a little bit better, see my comment.

Also did you try to reproduce the issue demonstrated by Filipe with this change: #12482 (comment) ?

[cyrillefr]

Hello @rioug ,

I have not tested the case shown by @filipefurtad0.
I do not have enough data locally.
Furthermore, I do not see clearly the issue.
I see overlapping selects but it is because clicks are fast paced.
May be @filipefurtad0 can test my branch ?

[mkllnk]

Very clever solution.

Can you elaborate a bit more what the advantage of this is?

Effects that I could imagine, but I haven't measured any of this:

• The transferred HTML is smaller. This doesn't really matter with compression though because repetitions are well compacted.
• The browser might render the page quicker because it doesn't have to render all the options to start with.
• The browser does more work on focus because it has to build the options which would otherwise already be rendered.
• Were the producer options cached before? If not then this new approach will save us a lot of database queries and building of options on the server. If it was cached then there's no big benefit in rendering it only once.

My main question is probably: Which solution is less work for the browser? And maybe the answer depends on the size of the product set and how many products you edit. If the list is big and you edit only one product, the new on-demand building of options is probably better. If the user edits every product on the page then it doesn't help.

I guess that you are on the right path here but I don't find the answer straight forward.

Anyway, very well done!

[mkllnk]

What if there is only one option? It will try to populate this on every focus, right?

[cyrillefr]

Yes, on each focus, fetchProducers will be called.

At first, there is only one option (the selected one), so the select will be populated.
After that, the number of options will always be superior to 1 and there will be not new attempt to populate the select.

[rioug]

Looks good know 👍 It will be interesting to see if resolved the issue that Filipe found.

[dacook]

I just came across this PR and had a quick look. Thanks for working on this!

This partial is repeated for every product row, yet it appears the intention was to only include the template once. When the controller searches for the element by ID, it will simply find the last one (standard browser behaviour).

This is ok, it would work, and as Maikel mentioned the compression will take care of most of it. But it looks like it should be very easy to remove the duplication by moving the template to another partial. So if you have time, feel free to go ahead update it ;)

[cyrillefr]

Aaah, my bad. I just pushed a correction.

[dacook]

Thanks, but i can see:

• this is still repeated for every product.
• producer_options is no longer needed in product_row
• options_for_select doesn't need a second parameter for selected value (tomselect will need to choose it for each product when initialised)

But first let's see if we can confirm a performance improvement before progressing.

[filipefurtad0]

Hey @cyrillefr ,
Thank you for working on this.

I went through the scenarios you've suggested:

• In V3 toggled mode, as an admin or producer
• Visit admin/products
• There should be no change with the current display of selects - OK -> I could not spot a difference visually or functionally
• The same behaviour should be seen: change one item and page should notice - OK
• Changing a producer for a product should work as expected - OK

Unfortunately, I could still reproduce the issue:

Indeed, it is related to fast pace clicking. It is noticeable how dropdowns take some time to open, after clicking. From a usability point of view, it is difficult to say, in a qualitative way, whether the PR brings improvement - although this was my first impression. In any case, I've tried to measure this with Lighthouse. Here are the results:

Before this PR

After this PR

We can see that:

• Total Blocking Time indeed is reduced
• Interaction to Next Paint (INP) is increased

It's hard to say whether these results are meaningful. I guess we might need more runs to account for variability.

In any case, and on this last point:

• From 10 items or more, a search input must be visible, but not under 10 or 10

I'm not sure I understand the test case. I've switched to a producer with one product only, but can still find the search input in the page:

What do you think @cyrillefr ?

[cyrillefr]

Hello @filipefurtad0 ,

I don't know how to improve the usability with long lists, maybe it has to do with too much data is select boxes.

Regarding the input and the 10 threshold, it is the input box that appears on each select box that has 11 or more options and not the input that appears on top of the page.

[dacook]

it is the input box that appears on each select box that has 11 or more options

Here's a (low quality) screenshot of one for example:

[dacook]

I just had a look at a super-admin user on current fr_prod and fr_staging, and found that there's already quite a delay when opening producer dropdowns.
When testing on dev with a smaller dataset, I found no delay whatsoever.

The reported increase in delay is a concern. It looks like there are different performance bottlenecks to look at.

So from what I can see, unfortunately this PR doesn't seem to bring a benefit. But it has helped us learn a bit more about the performance, thanks for your contribution. I think we should pause on this, re-evaluate the problems and prioritise along with other priorities.

I'll discuss in #backoffice-ui-uplift