Instantsearch.js: Browsers crash if too many widgets are created.

[aviatrix]

Do you want to request a feature or report a bug?
This is a bug

Bug: What is the current behavior?
I have a case where i want to have 50 widgets, and the browser crashes.
Edge (latest) - total page crash , Chrome (latest) - total page crash, Firefox (latest) - popup shows to wait or stop, if you wait it renders the page and up to 24 widgets.
If the widgets are 24 or less it's all good.
Bug: What is the expected behavior?
Browser doesn't crash if the widgets are more than 25
Bug: What browsers are impacted? Which versions?
Edge (latest), Chrome (latest), Firefox (latest)
Bug: What is the proposed solution?

Feature: What is your use case for such a feature?
I want to make a page that can filter objects that have many properties
What is the version you are using? Always use the latest one before opening a bug issue.
2.4.1

[Haroenv]

Hey! It would be nice if you could share a reproducing fiddle, so we can see if it's purely the number or the exact combination you use. Feel free to share it on [email protected] and mention this issue if you'd rather not share it publicly. Thanks!

A starter template is here: https://codesandbox.io/s/github/algolia/instantsearch-templates/tree/master/src/InstantSearch.js

[aviatrix]

Hey @Haroenv , here is a sample of the site when it crashes with too many widgets.
http://scrapecity.dotfinity.eu/

Also, please notice that the selected filters on the top are more than the rendered on the left.

[bobylito]

I could reproduce the issue with your link, thanks @aviatrix. I'm not quite sure how to proceed to fix this yet. It might take some time and I guess there will also be a higher bound on the number of widgets that we can handle in the browser.

From a UX perspective maybe it's not ideal to display 50+ filters. Maybe you could organize them in panels and add or remove widgets dynamically?

[aviatrix]

Hey, thanks for looking into this!

You are totally right about the UX, but we are still at a prototype phase and i wanted to have all options filterable untill we can figure out how to do things and what to keep/remove in general and what to hide.

For now I will try to add them dynamically and see where that goes :)

[bobylito]

@aviatrix did you manage to do something by dynamically adding / removing widgets?

[aviatrix]

I've tried the following thing so far : have 5-6 widgets declared before instantsearch.start() and the rest declared right after start (without delay) what i've observed is essentially the same behavior : search initializes the 5 widgets, does a search and the second it starts loading all those other widgets it still crashes. In addition it also does a lot more HTTP requests to the search api as the widgets are added instead of one or two ( before start and after start ).

So now i'm experimenting with the vue.js version to see if it's any better.

[aviatrix]

Happy to report that on first glance the vue.js version works nicely with 50 widgets and renders instantly.

The instantsearch.js version however crashes after 24 widgets even if i add the widgets post start or delay the start for 10 seconds after adding all widgets. I've also noticed that FF now reports out of memory exception.

[bobylito]

Happy to report that on first glance the vue.js version works nicely with 50 widgets and renders instantly.

Well that's both great and bad news. Thanks for doing the hard work of testing the limitations. I will dig into that...

[bobylito]

I ran some tests this weekend and I found that the time is mostly spent inside the slider widget. After removing all slider widgets from the example, the time of render went from 15s to 0.5s and no crash anymore.

The time is mostly spent when computing snap points computeSnapPoints.

[samouss]

For the computeSnapPoints (same for computeDefaultPitPoints) we should avoid to do it on every render. We can cache the results and trigger the computation from willReceiveProps only when the dependencies changed (min, max, step).

[bobylito]

Well that's an idea, but that won't change the problem for the initial rendering. It will only make the subsequent render faster.

[bobylito]

I've continued investigating the issue here. It seems that one of the facet values DynamicContrastRatio has a range of [0 - 1000000]. I removed the widget that was using this facet and the 49 others widget behaved correctly. I also tried to remove the generation of snapPoints and it worked like a charm.

@aviatrix you could use instantsearch.js and use another widget for the dynamic contrast ratio for the moment.

On our side, we should remove the snapPoints generation if step is not provided.

[aviatrix]

@bobylito Excelent! Would just removing the DynamicContrastRatio speed up things significantly on its own or we need to also wait for new version that includes the step fix on your side?

[Haroenv]

Removing it for now and adding it back when we have the fix will do the trick @aviatrix