4 ms·

Thinking of Redux as a 'detached state tree' that the whole app can subscribe too might give a better picture of some problems that it is solving. In React, whe

Thinking of Redux as a 'detached state tree' that the whole app can subscribe too might give a better picture of some problems that it is solving. In React, when you lift state up and up, you mostly end up tracking lot of irrelevant state in the top most component which kind of weirdly manages lot of state just for their children. There are some genuine use cases of Redux by tracking the whole 'app state' in a detached way, safely update/transform them (with pure functions) and more importantly you could just subscribe for necessary data at any level. Context API is helpful, yes, but Redux (or MObX or any state management tool) is still helpful when done right.

kerkeslager 8y ago
> In React, when you lift state up and up, you mostly end up tracking lot of irrelevant state in the top most component which kind of weirdly manages lot of state just for their children. I'm not sure why you think the data is irrelevant, or why the component manages it "weirdly". I'll point out that these top components actually share a lot in common with Redux, except that they can be duplicated and composed with other components, if for example you decide to drop your top component inside of a larger application, and the toplevel components actually don't end up managing data they don't have to (LESS "irrelevant" data than Redux, perhaps?).
- pault 8y ago
  > I'm not sure why you think the data is irrelevant I believe the GP meant "unrelated". Can you drop your top level component into another application with different children and still have it work? Can you move the child components to another view tree and still have them work? It seems like what you are describing is a top level component that is tightly coupled to its descendants with too many responsibilities. In the ideal react app architecture you should be able to take any component and move it anywhere else in the app and it should Just Work. This is the problem redux is supposed to solve, and I would argue that by enforcing an explicit pattern that most experienced react developers know, you will get closer to that ideal than if you have a variety of home grown solutions that vary from project to project (and even from developer to developer on the same project). "The Tyranny of Structurelessness" etc etc.
  - kerkeslager 8y ago
    > Can you drop your top level component into another application with different children and still have it work? Yes, it's a matter of passing the child into the parent as a prop. > Can you move the child components to another view tree and still have them work? Yes, this sort of thing is exactly what you get for free by doing things the way I describe. > In the ideal react app architecture you should be able to take any component and move it anywhere else in the app and it should Just Work. This is exactly not what happens in Redux projects in my experience.
    - pault 8y ago
      > This is exactly not what happens in Redux projects in my experience. Sorry to beat this dead horse, but how does redux, which binds data directly at the level of the component that displays the data, make portable components more difficult than vanilla react where stateful components and functional components are tightly coupled? Do you have links to a gist or something so I can see what you're describing?

kerkeslager 8y ago

> In React, when you lift state up and up, you mostly end up tracking lot of irrelevant state in the top most component which kind of weirdly manages lot of state just for their children. I'm not sure why you think the data is irrelevant, or why the component manages it "weirdly". I'll point out that these top components actually share a lot in common with Redux, except that they can be duplicated and composed with other components, if for example you decide to drop your top component inside of a larger application, and the toplevel components actually don't end up managing data they don't have to (LESS "irrelevant" data than Redux, perhaps?).

pault 8y ago
> I'm not sure why you think the data is irrelevant I believe the GP meant "unrelated". Can you drop your top level component into another application with different children and still have it work? Can you move the child components to another view tree and still have them work? It seems like what you are describing is a top level component that is tightly coupled to its descendants with too many responsibilities. In the ideal react app architecture you should be able to take any component and move it anywhere else in the app and it should Just Work. This is the problem redux is supposed to solve, and I would argue that by enforcing an explicit pattern that most experienced react developers know, you will get closer to that ideal than if you have a variety of home grown solutions that vary from project to project (and even from developer to developer on the same project). "The Tyranny of Structurelessness" etc etc.
- kerkeslager 8y ago
  > Can you drop your top level component into another application with different children and still have it work? Yes, it's a matter of passing the child into the parent as a prop. > Can you move the child components to another view tree and still have them work? Yes, this sort of thing is exactly what you get for free by doing things the way I describe. > In the ideal react app architecture you should be able to take any component and move it anywhere else in the app and it should Just Work. This is exactly not what happens in Redux projects in my experience.
  - pault 8y ago
    > This is exactly not what happens in Redux projects in my experience. Sorry to beat this dead horse, but how does redux, which binds data directly at the level of the component that displays the data, make portable components more difficult than vanilla react where stateful components and functional components are tightly coupled? Do you have links to a gist or something so I can see what you're describing?