> 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".
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.