Before Hooks were really a thing, the most definitive design pattern I had experienced in React was the "Redux with Container Components that encapsulate Presentational Components" pattern. There was a very clear distinction between Class-based (stateful) components, and Functional (stateless, presentational) components. You'd be encouraged to "Lift state up" and -- from what it seems like to me -- store as much state as you can in a single container component so that it can be drilled down maybe 2 or 3 levels at most to presentational components. More levels than that, and you were probably looking at a new Stateful component.
And of course, all Class/Stateful components were connected to Redux store.
Then Hooks came about, and the line between "which components should or shouldn't have state" became very blurry. And let's not even bring up Context.
An aside: I'm not even sure if Context is considered a stable enough solution (yet) to replace Redux completely for apps of all sizes. Context usage seems like the wild west at this point between people trying to use it exactly like Redux, to people building libraries like reactn and constate around it, and using each Redux reducer as an individual context or something. Who knows.
Are Hooks supposed to encourage us to decentralize state by writing more stateful components? Or are they just supposed to be a new paradigm for writing stateful components, and the idea of big centralized stateful components isn't going away?
Top comments (1)
That line should still be in the same place. If we are talking about state management, using
hooksorcontextis an implementation detail.I don't think that's the goal. Hooks are a way to reuse logic, that's it. They act (kinda) as a replacement for
mixinsor thehigher order componentspattern.