This is confusing because before component models, everything was a global.
I do agree about one thing though, before hooks, the standard recommendation was redux (or similar) I kept SCREAMING that it was a giant global anti-pattern. I don't think anyone understood that for the first 5 years of React. It seems like that whole thing is corrected now.
> This is confusing because before component models, everything was a global.
Hot take: I'd argue this is confusing because (almost) everything should be a global in UI development. Plenty of websites were built in PHP and basic Javascript with (gasp) globals! I guess some folks don't understand that people have been making pretty complex web apps since before 2013. It's monumentally counterproductive having to deal with state management in like 40 nested components because you just want the username and user email to trickle down.
So people re-invented global state but we call it Redux now. It's a parody of a parody.
Globals are bad in general. Things should be as specific as they can be. If you were playing a tetris game and suddenly wanted to upgrade it and make it a DUALING side-by-side tetris game, then all your state is going to collide. It would have been better to define your <Tetris> tag to have it's own state.
It goes further than that, but essentially it's all about maintaining a context for a thing. I have a patient, that has meds and records etc, I need to keep that contained to one place so that I can have a SECOND patient at the same time (if I am writing an EHR for example). The original "UI of the web" was Open a thing, edit a thing, save and close a thing. And all of that was like 6 full page refreshes.
More apps should be like Trello, for example, where you can just edit a lot of state on lots of different objects super quickly. Globals don't work well for that.
I’m not convinced that this argument holds for the specific case of “a single global source of truth, with a structured and enforced update mechanism.”
Let’s expand your <Tetris> example. You didn’t specify whether both players are on the same computer or not. I agree that my <Tetris> instance should not depend on or conflict with any other player’s <Tetris> instance. What does that look like in practice?
Whether it’s local or internet play, we need a way to isolate each player’s game state. Each <Tetris> instance should only be concerned with displaying a single game state, and responding to at most one player’s inputs. What happens outside of that is not its concern: things like maybe logging into a server, knowing that there is a second <Tetris> instance running alongside it, knowing where garbage blocks came from, maybe knowing that my friends are online, etc.
To me, the obvious choice is to use something like
<Tetris state={app.player[0].gameState} />
If this is local multiplayer, there could be another <Tetris state={app.player[1].gameState} /> which has different input bindings. If it’s internet play, it could look the same and not have anything bound to inputs.
In either case, <Tetris> knows nothing about where its state comes from or goes to. But that state has to live somewhere for the app to access it, so where is it stored?
Redux doesn't really have anything to do with passing data around in an app. Redux is only a state manager and reducer. Accessing that state manager in components is usually done using a React context provider (in a React app... Redux can be used with any library).
Recent versions of Redux include a useSelector hook that manages that context provider for you, which is probably where some of the confusion comes from.
> Recent versions of Redux include a useSelector hook that manages that context provider for you, which is probably where some of the confusion comes from.
There's no confusion, Redux absolutely does deal with passing around data in your app, that's why there's literally an FAQ dedicated to how to do it[1][2] -- and whether or not it should be done via setState or the Redux store. It's a stupid solution to a stupid problem, but now we're stuck here until TikTok will inevitably come up with their own "ground-breaking" React replacement in 5 or so years and we'll start the whole cycle again.
Nothing on that page is about passing data around. It's about whether or not you should manage state locally in the component, or globally in the state manager. In cases where you choose to hold the data in the global state manager you access the state manager (in React) via a context provider. That context provider is not a part of Redux - it's react-redux as isakkeyten noted.
I understand that this probably feels incredibly pedantic but it's quite important to frontend engineers like me. Redux is only a state manager, and it is not a React library.
well I sort of love to be the guy that asks if there is some other library that binds to redux that I will love, and thus also cause me to feel some sleight love by association for redux?
>Redux doesn't really have anything to do with passing data around in an app. Redux is only a state manager and reducer.
If you tell component X what state component Y is in you are in some way passing data around in your app. Since Redux manages the state it is part of the chosen strategy for how data should be passed around in the app.
In the same line of thinking: I always wonder why people look bad at you if you suggest to use an event bus or dispatch events on an element but it is totally fine to dispatch actions in redux. I don't see the difference other than one being cool and the other being "old".
Hooks don't really change anything about whether or not you use Redux, though. The only real difference is that there's now the `useReducer` hook, but that's just a different mechanism for updating the same component state we've always had architecturally.
FWIW, I maintain Redux, and I've written extensively trying to clarify when it does and doesn't make sense to use Redux, and how to use it the right way [0] [1] [2] [3] [4] [5]. No question there's been a lot of FUD and misconceptions about that over the years, and I wish I didn't have to spend so much time on this topic, but lots of people never look at our docs and actual recommendations.
Also worth noting that our Redux Toolkit package [6] and React-Redux hooks API [7] have made Redux _much_ easier to learn and use than it was previously, and we get a ton of very positive feedback about that.
Before react and vue everyone could create a mess, but it was not mandatory. Desktop frameworks always used sorts of controller hierarchy vs view hierarchy separation and didn’t store global data. There was decent ui before web/react (though it may sound crazy to react guys).
I don't think anyone understood that for the first 5 years of React
I bet that millions of developers who were not on the ~awesome hype train~ would look at this statement with a great confusion.
I’m not a react guy though, can someone explain where the data usually resides now? Right in a component state, I guess?
I do agree about one thing though, before hooks, the standard recommendation was redux (or similar) I kept SCREAMING that it was a giant global anti-pattern. I don't think anyone understood that for the first 5 years of React. It seems like that whole thing is corrected now.