I have been reading up on Redux, and it solves a great number of problems. But in essence it is simply a central 'true' storage.
Intuitively though I find the fact that the state is still passed through props or context inelegant.
Aside from disk i/o speeds, why not use the local cookie store as a central data store? This would eliminate the need for passing the data along through components.
The only challenges I see is data safety, but that is not an issue for all applications.
Elaborating based on Dave's comments. My actual question is more about the possibility of having a central Redux style store without needing to actively pass along the state through props or context. Cookies seemed like an interesting first avenue to explore.
Fast forward a few years of experience:
react-redux-persist
) but you wouldn't rely on it performance wiseAs a rule of thumb - and one shared by one of Redux's creators, Dan Abramov - you don't need to use Redux unless you're unable to manage state within React or other front-end frameworks you're working with.
Redux is most useful in cases when:You have large amounts of application state that are needed in many places in the app. The app state is updated frequently. The logic to update that state may be complex. The app has a medium or large-sized codebase, and might be worked on by many people.
useReducer() Hook This is an alternative to setState. It works exactly like Redux. You have a reducer and you dispatch actions to the reducer to mutate the state.
js, MobX, Flux, React, and RxJS are the most popular alternatives and competitors to Redux.
Because you'd be endlessly retrieving cookie data and deciding if you need to re-render. This is no better than scattering data in the DOM or arbitrary web DB stores: the end problem is the same in that it's disconnected from rendering.
It completely removes one of React's benefits from your code: the whole point of having state and properties in React is that it handles re-rendering (or lack thereof) for you.
The Redux pattern is more than just having "central storage", which could be implemented in countless arbitrary ways. It also specifies how that storage is accessed (streams of actions) which provides a number of additional benefits. That's orthogonal to how the data is stored.
If you want more meaningful replies you'll need to defend your statement that "passing data through props or context is inelegant". It's one-way data flow; it's not inherently inelegant.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With