The bit that is g(state, userInput) => newState is the hard part. In particular managing the scope of that newState.
Oh, and sometimes you need to handle h(state, asynchronousData) => newState too.
And then comes the fact that even though your f is _pure_, it also has to be _fast_, because it's going to run every time you get a newState.
It's like you're speaking a different language to me, and I find that so weird considering we're using the exact same framework. How am I not having any of these issues?
I'm honestly at the point where I wonder if y'all are making things harder on yourself somehow, because I could see how getting obsessed with counting every single re-render and trying to overoptimize would result in the stuff you're saying while not actually impacting perf in a meaningful way.
When I do encounter a component with countless re-renders as described, it is usually painfully obvious what causes them and easy enough to fix.
I think we're going too far if we're expecting React, or any framework, to be fool-proof to the point that we can just throw "whatever" we want at them and expect it to have peak performance.
Timing-based UIs are (such as a sequence of triggered animations) can get really messy really fast. I've seen some really messy bugs in a app that had visuals and audio tied to different timers and user inputs in the app. We eventually moved all time-based animations to observables, which helped some
Something I don’t quite get, doesn’t useRef just solve the re-render issue?
I had to eventually claw my eyes out and that solved part of my problems, at least I did not see the boilerplate and the ugliness.
Then soon after that we worked on a similar thing (form + draggable carousel with snap to grid animation) in Angular with Material.
And my conclusion is that whichever framework you pick, whatever libraries you end up using, you must have a strategy to allocate your time and maintenance budget, and many many many times the sane compromise is to write something in raw JS and encapsulate that in whatever the framework gives you, and move on. Don't try to solve it within the framework, because it's just not worth it.
I don't know if we have any "timing" based components, though we manage global state using Apollo Client and again, haven't really had any issues with that.
- https://redux.js.org/usage/side-effects-approaches#recommend...
What I like about sagas are their simplicity & power (once one understands how generators & effects work), plus the eventChannel feature which lets one integrate with non-redux events. Good TypeScript support is a problem though, and I've had to resort to typed-redux-saga :/
- https://redux-toolkit.js.org/api/createListenerMiddleware
- https://blog.isquaredsoftware.com/2022/03/designing-rtk-list...
Event channels was something we intentionally _didn't_ try to replicate per se, and tbh I've never tried to use those myself. (But, I _suspect_ that you might be able to do something similar with listeners even though we don't have a specific replacement built into the listener middleware, and if you do I'd love to see an example in action!)
If you get a chance to try out listeners in your project, I'd definitely appreciate feedback on how well they work out for you - whether they solve your current saga use cases, what cases they _don't_ handle, anything we can do to improve the listener API, etc.
Sagas keep state (and you should keep most state in the redux store, anyway).
So, yes, you can go wrong, as with everything else. But it's better than using useEffect as an async framework.
Remove most logic from the components into sagas,thunks and selectors.
That way your components will be smaller, more testable, easier to change, easier to reason about.
Your app is the store, not the DOM.
It really makes things much simpler. The trick is to keep all the state in the store, including when things are loading, when some user interaction is happening but not yet complete, etc.
From your comment, it seems like there may be some problem if the user is interacting somehow, let's say in the middle of doing a drag and drop, and some data update comes in from a websocket, right? Well, if that's going to cause a problem for your render it's because apparently your data-updated function h needs to know if the user is doing a drag and drop. That should get put in the state when the user starts the interaction, and now h can know about it and react correctly.
Yes, it's more complicated than just have some component render based on the data you receive, but that's because it turned out that your app was more complex than you thought, it has more states you need to care about.
There's no magic wand, but this stuff works, just adds some boilerplate code but I don't mind.
Didn't have to in the past. Back with class-based components we had shouldComponentUpdate(), and lost that when components switched to pure functions.