5 ms·

Was on a team at a large company - and the architects had a decree that everyone must use React - good decision. Except one problem was that everyone was just u

Was on a team at a large company - and the architects had a decree that everyone must use React - good decision. Except one problem was that everyone was just using Redux like it was part of React or something. I don't know how many components that had to maintain their own state got stuck in Redux nightmare land where special keys were being used to keep each component separate - it was a complicated mess inside the react component. This component didn't map to a single concept of state, instead many "copies" and different versions of that copy could be on the screen at once - and no one really "got it" that they were feeding really deep into a major anti-pattern. I kept pointing out to members of the team that even Dan Abramov's post about maybe not needing Redux... but it fell on def ears like I didn't "GET" redux. I totally understand the enticing time-travel feature, but I think too many people jumped on the ship before it was ready for the use-cases different folks had in mind.

0xCMP 8y ago
Yea seems like people reach too much for larger "state management" via Redux/Mobx/etc. too quickly without thinking what that means instead of just using State updated via callbacks passed as props. Clearly Redux solves the times where doing that isn't really clear or gets complicated, but often times it sounds from Twitter + Conversations that everything is getting thrown in to Redux for no reason.
- ojosilva 8y ago
  I resisted for a long time, but finally switched from a callback model to Mobx and the reason was that ShouldComponentUpdate and ComponentDidUpdate started becoming unbearably hard to manage. So state management libraries are not solving a unsolvable problem, they are here so that we can write cleaner, more efficient code that potentially can become more performant. At least that's what happened in my case.
  - baddox 8y ago
    Can't you use pure components as long as you make sure that all your callbacks are called with new objects, e.g. using the JavaScript spread notation? I think the bigger reason that a global state management system becomes necessary is when the shape of your component tree doesn't closely match the shape of your state tree, because that means state (and callbacks) need to be passed down through components that don't care at all about that state simply because one of their distant descendant components does care about it.
lobster_johnson 8y ago
This type of data flow where components need to plug into multiple instances of the same type of state is an area where Redux doesn't help you, and solutions tend to be ad-hoc, using things like the "special keys" you mention. A challenge I had recently was a location form field, where the user is offered autocompletions as they type. The autocompletion state is specific to the component; every field needs its own unique state. So to represent this with Redux, the component has to generate a "state ID" (basically just "new Object()", as I recall) that serves a unique identifier that it can request lookups under. The autocomplete() action then has to take a state ID as a parameter, and associate all lookup state with that ID. Internally, I implemented this as a layer on top of the autocomplete engine, so that the underlying layer didn't know about the ID. Even so, it wasn't beautiful. And of course it was susceptible to leaks -- it was necessary to "unregister" the state ID on unmount. It was unpleasant enough that I considered not using Redux, but I've done that before, and I really wanted the whole state transition machinery. Has anyone created a solution for this, I wonder? It's possible that a new Redux store per field would have solved everything. But can you connect a component to multiple stores? Some components need to have instance data and access the global store (e.g. current logged in user).
- asynchrony 8y ago
  You could use Symbols or create a Symbol type (just an object with .toString method) to make the state IDs more manageable. It does amount to writing a memory manager similar to object pooling in a game engine. It's not that bad if the codebase has one convention for how to manage it, but if every case is adhoc it gets nasty quickly. In general the solution would be some kind of class with .acquire and .release methods to create/recycle objects as needed. It comes up often enough that I'm a little surprised there isn't at least one or more popular libraries for it.
  - underwater 8y ago
    I think the fact that you’re storing UI-specific data (even if it is just IDs) in Redux, is a sign that it is the wrong tool.
deleted 8y ago
[deleted]
Marazan 8y ago
One of my best contributions to the team I work on was, when faced with them having a Redux problem, telling them to stop using Redux for the small app they were creating. I love Redux, I think it deserves the title of genius, but you often do not need it.

0xCMP 8y ago

Yea seems like people reach too much for larger "state management" via Redux/Mobx/etc. too quickly without thinking what that means instead of just using State updated via callbacks passed as props. Clearly Redux solves the times where doing that isn't really clear or gets complicated, but often times it sounds from Twitter + Conversations that everything is getting thrown in to Redux for no reason.

ojosilva 8y ago
I resisted for a long time, but finally switched from a callback model to Mobx and the reason was that ShouldComponentUpdate and ComponentDidUpdate started becoming unbearably hard to manage. So state management libraries are not solving a unsolvable problem, they are here so that we can write cleaner, more efficient code that potentially can become more performant. At least that's what happened in my case.
- baddox 8y ago
  Can't you use pure components as long as you make sure that all your callbacks are called with new objects, e.g. using the JavaScript spread notation? I think the bigger reason that a global state management system becomes necessary is when the shape of your component tree doesn't closely match the shape of your state tree, because that means state (and callbacks) need to be passed down through components that don't care at all about that state simply because one of their distant descendant components does care about it.

lobster_johnson 8y ago

This type of data flow where components need to plug into multiple instances of the same type of state is an area where Redux doesn't help you, and solutions tend to be ad-hoc, using things like the "special keys" you mention. A challenge I had recently was a location form field, where the user is offered autocompletions as they type. The autocompletion state is specific to the component; every field needs its own unique state. So to represent this with Redux, the component has to generate a "state ID" (basically just "new Object()", as I recall) that serves a unique identifier that it can request lookups under. The autocomplete() action then has to take a state ID as a parameter, and associate all lookup state with that ID. Internally, I implemented this as a layer on top of the autocomplete engine, so that the underlying layer didn't know about the ID. Even so, it wasn't beautiful. And of course it was susceptible to leaks -- it was necessary to "unregister" the state ID on unmount. It was unpleasant enough that I considered not using Redux, but I've done that before, and I really wanted the whole state transition machinery. Has anyone created a solution for this, I wonder? It's possible that a new Redux store per field would have solved everything. But can you connect a component to multiple stores? Some components need to have instance data and access the global store (e.g. current logged in user).

asynchrony 8y ago
You could use Symbols or create a Symbol type (just an object with .toString method) to make the state IDs more manageable. It does amount to writing a memory manager similar to object pooling in a game engine. It's not that bad if the codebase has one convention for how to manage it, but if every case is adhoc it gets nasty quickly. In general the solution would be some kind of class with .acquire and .release methods to create/recycle objects as needed. It comes up often enough that I'm a little surprised there isn't at least one or more popular libraries for it.
- underwater 8y ago
  I think the fact that you’re storing UI-specific data (even if it is just IDs) in Redux, is a sign that it is the wrong tool.

deleted 8y ago

[deleted]

Marazan 8y ago

One of my best contributions to the team I work on was, when faced with them having a Redux problem, telling them to stop using Redux for the small app they were creating. I love Redux, I think it deserves the title of genius, but you often do not need it.