Slider slow when onChange triggers redux state change

[fonty422]

Duplicates

• [X] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Steps to reproduce 🕹

Steps:

1. Create a react app with react-redux store
2. Create a virtual windowed list with accordions (allow for random size)
3. Add a slider (normal Slider or MuiSlider component)
4. Have the onChange method call a redux action creator that sets some state
5. Observe the lag in the slider

Current behavior 😯

It appears as though when the slider is linked to an action creator that changes some state (even if it just creates a shallow copy of the state without changes), the slider shows awful lag. It appears to depend on how many other components are on the page at the time. a lot of accordions seems to seriously affect the performance.

Expected behavior 🤔

Slider to change value and update a data store without significant lag.

Context 🔦

A code sandbox with version 4 does not appear to have an issue, but my app with version 5 does. As the sandbox doesn't seem to handle version 5 well i can't create a test case there to determine if it's my code or the new MUI version.

Your environment 🌎

No response

[fonty422]

Oh, and a link to the sandbox with v4 that doesn't display the issue.

[siriwatknp]

Oh, and a link to the sandbox with v4 that doesn't display the issue.

Your link does not work. Can you also provide a Sandbox for v5?

[fonty422]

Thanks @siriwatknp. Thanks for your time. I have no idea how that code broke... it was working perfectly fine when I added the link and I can't see why it's not working now as it's complaining about things that aren't broken. Sandbox doesn't appear to have support for version 5 properly - it breaks all the time, so I can't provide that.

In any case I think I may have just shown that it's not the slider - I created a new react app with the virtual list and slider but had not troubles at all. I suspect, although I can't find it to save my life, that somewhere there are many components that are subscribed to either the output of the slider directly, or something to do with that data and so I end up with many renders. I'm just spending a bit of time refactoring/building my app up from scratch (which is a little time consuming and tedious), but I hope to find either the point where it becomes clear the slider is the issue or that the issue magically goes away. I should be able to update in a few days. Prompt me if I haven't closed this in a 7-10 days or given a full update.

[fonty422]

I think I've found the culprit and also why I hadn't noticed it until late. It appears that the slider is prone to getting stuck while the virtual list below updates and re-renders. I wouldn't have thoughts it was such an issue and that react would be better at only processing changes to the DOM. I'm currently trying to provide a sandbox with the correct versions of everything, but it appears to be having an issue with redux returning an object instead of a class component on the sandbox, but not on my local machine, so not sure what's going on there. I'll try pull back to react v 17 and try get this to you soon.

[fonty422]

I can close this now as I have found the root cause which is not directly as a result of the slider, although the slider did trigger the issue. The issue was the Accordion components were doing something stupid where I had them subscribed to a list of data and they had to filter it to find the data that refers to them. I changed this to a dict/JSON type and they now just do a key lookup and it resolved all the issues. But I think that this was visible because the hover/touch listener for the slider triggered react to check for changes across, which was not negligible and they all recalculated and ended up repainting. When there were only a small number of them it was OK, but as the number grew it became worse.