Earlier quoted context omitted.
The bit of react that is f ( newState ) => UI is the easy part. 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 .
In my experience redux-toolkit + redux-saga for async stuff usually work really well. In case of performance problems one can go with profiling + targeted optimisations (e.g. a separate store, some locally managed state).
- https://redux.js.org/usage/side-effects-approaches#recommend...