Why not use cookies instead of Redux?
Asked Answered
C

1

7

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:

  • The point of redux is immutable data flow, cookies are more like a global variable
  • You could use the cookie store or local storage API to store data (see react-redux-persist) but you wouldn't rely on it performance wise
  • We have no control over cookie handling (the browser decides that) so relying on it is a bad idea for compatibility
Carey answered 28/11, 2016 at 16:13 Comment(2)
I'd rather have full control / containment of state within the app. What if a browser is set to deny cookies?Gervase
@Gervase good point. I had a similar consideration yesterday where a user complained that many webpages do not function well without javascript. And here I am building in almost exclusively JS...Carey
J
11

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.

Jacobba answered 28/11, 2016 at 16:21 Comment(4)
Thanks very much for the perspective Dave! What I mean to say is not that the Redux control flow bothers me, quite the contrary. Using reducers and dispatching actions is brilliant. Of course elegance is relative, the reason I feel that way is Redux still requires the passing of a prop or setting of context rather than having a way of 'directly' connecting to the central store. Most likely this is purely an artifact of being used to non-react database thinking. My question is purely, why not use Redux, but have a globally accessible store, for example through cookies.Carey
@Carey It is globally accessible, it just happens that with React components the state is mapped to props (if you're using react-redux `connect). The problem with "globally accessible" is that it's globally accessible, e.g., you have no means to determine why state changed. Again: how it's stored is immaterial, you could write a cookie back-end (but don't, because cookies have max sizes, IIRC) or LocalDB or whatever, but then access isn't controlled, and you won't get the automatic updating etc. It's still not clear to me what your actual underlying issue/disagreement is.Jacobba
It is not so much a disagreement or issue. More a curiosity stemming from always trying to find the optimal way for my personal workflow, which is why I greatly appreciate your input.Carey
@Carey Understood-I'm just trying to parse what the underlying concern is. So far I don't quite get it. Being relatively new to Redux I've also been doing a lot if thinking about it, related patterns, and alternatives.Jacobba

© 2022 - 2024 — McMap. All rights reserved.