Redux: Perhaps we lost the ground to use redux state from the beginning ?

[be-next-hotdog]

Heyyi buddies,

During last weeks, we focused on achieving a SearchKit tool with redux. But to be honest, we observed a poor performance while typing the keywords on updating the state which includes the search result. Of course, we did reviewed several old articles yet, nevertheless, their core issues do not match our features background.

We should agree that in most cases, a disruptive change will occur in returned search results in pace of typing / adapting the keywords. So that it would make less sense to expect immutableJS (or others similar ways) to improve our fettle.

So anyway, what should be the best solution ?

Looking forward to giving us more advices, thx a lot !

[markerikson]

This question isn't very clear. Are you saying you're concerned about the delay in updating controlled inputs when every input onChange event dispatches a Redux action (such as {type : "SEARCH_VALUE", text : "a"}, {type : "SEARCH_VALUE", text : "aa"}, .....) ?

If so, the answer is probably to _not_ dispatch an action for every key input. Use local component state to control the input, and debounce the actions.

Beyond that, it would help if you could better explain what specific problem you're seeing, and what you're asking. Also, as this is sounds more like a usage question than a problem with Redux itself, you might want to post this over on Stack Overflow instead.

[mrtnbroder]

Basically what @markerikson said. I can recommend using https://github.com/acdlite/recompose for exactly this. You don't need to add a global redux reducer and handle every onChange event. Keep it within the local component and use it together with recompose withReducer. That way you're keeping the state at the component level and still have the benefits of redux (which are, predictable state changes).

[jfrolich]

Did you have the performance issues in production? My experience is that there is significant overhead in development, making state updates very slow (also because every state change is saved), but it flies in production. A lot of form libraries use redux state for onChange, so it should not be a huge problem for most apps. Perhaps it helps to profile your reducer performance and see if there are major bottlenecks (in production).

The only case where I had trouble with slow reducer performance was when resizing a component, where I updated the redux state in real time while resizing, which was fixed with using local state until the resize was finalized.

[timdorr]

Closing this out since SO is probably a better forum for this sort of thing.

[gaearon]

Also some such issues were actually React 15 regressions in development, which were fixed in 15.3.x.

[timdorr]

Yeah, to be more specific, it's often problematic to generalize performance issues as something to do with a library or architectural design. Sure, it can be systemic, but there is often a simple fix or two that can at least move the ball forward.

For example, I resolved some perf issues with our app today simply by removing some image preloading code. It was too aggressive and had a net negative effect on perceived performance. A simple change of 3 lines of code that sped things up noticeably. It's not as fast as we can make it (we're still in the midst of building it), but it was a low effort, high impact change nonetheless.