Not GP but I can try to explain. React tries to be as functional as possible, but components are still often stateful. For example, an accordian component [1] could have a `collapsed` boolean state. This `collapsed` state makes sense within the context of the accordian component.
Now imagine if you tried to move the state out of all your components into a single location, so that your components can be stateless functions. Now that your variables are out of context and might collide with each other, you might need to rename this `collapsed` state into something like `landingPageItem4AccordianCollapsed`. This is why you shouldn't use global state (like Redux) for everything, and it's often best to keep state close to the UI component it belongs to. This keeps things grouped by context, and makes it easier to navigate and reason about the code.
I don't think that's right. I think you'd have a global state like landingPage.Items[].Accordion, and the accordion code in any location would be passed its state and messages already unwrapped by the parent. Nobody would need to know about its collapsed field or any other state it tracks for that matter
> I don't think that's right. I think you'd have a global state like landingPage.Items[].Accordion
Somebody correct me if I'm wrong, but I believe this is what React is already doing under the hood when you use useState(). React probably has some big internal global state, and then maintains mappings between state and components, so that when a component is re-rendered, React can pull up the corresponding state for that component.
So even though the components are technically stateless, they can still be considered "stateful" because each component has a corresponding portion in this global state. Notice how in your landingPage.Items[].Accordion, if you change the layout of your landing page, you might now have to change the structure of your global state as well. So this is why React's syntax for keeping the state definitions inside the component is so nice. It prevents you from trying to keep the structure of your global state and the layout of your components in sync.
P.S. I like your work on torrents :P I knew I recognized that username from somewhere
IMHO, Component style (React) and State style (Elm) can be interpreted as two styles of isolating (or decoupling), just very orthogonal to each other. Isolating is a very basic necessity for keeping complexity at bay.
Component style isolation works really well for "inner UI state", like your accordion example. But it quickly gets out of hand once you get to some non-UI state that is shared between a bigger component hierarchy.
State/View/Message isolation works really well for actually keeping the views pure and having only one change-message channel. But the state model quickly (and message handler) quickly gets huge. You also cannot publish/provide a small "component" with local state.
Now imagine if you tried to move the state out of all your components into a single location, so that your components can be stateless functions. Now that your variables are out of context and might collide with each other, you might need to rename this `collapsed` state into something like `landingPageItem4AccordianCollapsed`. This is why you shouldn't use global state (like Redux) for everything, and it's often best to keep state close to the UI component it belongs to. This keeps things grouped by context, and makes it easier to navigate and reason about the code.
[1]: https://getbootstrap.com/docs/5.0/components/accordion/