Actually, you do see a lot of questions and problems with the single state atom. In fact, I'd argue it's inherently a side step towards a future that has the best of both worlds: encapsulated state within components, but backed by some global state store invisibly.
This is exactly what Relay is by the way. You component asks for state, and gets it from a server. The fact that it comes through props is actually just a downgrade because it means you must now treat it as some special thing, and not variables.
In the ideal world, we can write simple components that fetch state from wherever (remote, local, global). They store that state into themselves, and it "just works". They can write back that state just like how they write variables. And all of this "local" state would really be backed into a global state store invisibly.
Local state - Pros: easy to reason about, easy to use. Cons: trapped in one place, inflexible.
Global state - Pros: can be backed in various ways, easier to share. Cons: Hard to use, harder to reason about.
Local state backed to global store - Has all the pros and none of the cons. Unfortunately doesn't exist yet today.
I do not quite agree with this. Though I acknowledge your sentiments :-)
1. Global state is easier to reason about. If you have a single state store expressed as a single object you only have to read one file to understand the complete state of your application. If you let local state express the state and the global state is invisible you have to look into all these local state files and compose the complete state in your head
2. When you define it as local state you risk conflicting with some state set in a different component
3. You still have to change state. If you define your state in your components you will also have to include all the state changing logic inside the component. Your components will become very hard to reason about. And what if two components uses the same state and both of them needs to update the state? You will need to put the same logic into two different components
4. You could say Relay fixes this, but Relay just handles one thing and that is state related to the server. We build applications that does a lot more than talking to the server. Changing the state of your application is a huge problem space and though Relay is cool technology I can not imagine anyone expressing and changing all their state using Relay. So you need some other concept(s) to change all the other state and multiple concepts for doing the same thing is harder to reason about
Personally I think local state is a bad idea and currently I also think Relay is too limited. When I jump into an application I need to reason about what state it handles. With a global state store I can do that. Then I need to know how that state can be changed. Ideally that should be one concept, but we usually have lots of concepts for changing state. Then I want to see how the UI is expressed. Components are great for that, except when they are filled up with state definitions and state changing logic.
So from my perspective I am also trying to contribute with a solution :-) www.christianalfoni.com/cerebral
1. Global state is easier to see on a high level, but harder to reason about. Local state is inherently easier to reason about: it's right there. Global state requires me now looking at actions/signals, global state structure, and then my component, and resolving the three.
2. They should definitely be synchronized, this problem is only specific to local state implementations today. If they aren't synchronized, thats simply at the lack of the system you're using. I'm not familiar with Om Next, but I'd guess it handles this for you (as could any system properly organized).
3. Not true. You could have state changing functions imported and used by multiple components. This is also easier to understand, in my opinion. I can see where the state is located, and still keep my shared state changing functions somewhere.
I do think local state is skewed negatively now because it's very poorly done. React, angular, all systems today make local state a total pain, opaque, and hard to work with. Om Next seems to be a step forward (I'm working on something somewhat related for JS that should make it better as well).
This is really interesting, we have very different perspectives on how to consume how an application works. Not saying you are wrong at all, just have different perspective :)
1. When I say "global state" I mean the actual state, actions and signals are state changers, not state. A global state store looks like this:
This is one file. If you use local state this example would be split into maybe 3 different files. I think we both agree it has to do with how many files you need to look into. And the amount of composition you need to do in your head.
2. It would be interesting to see Om Next in JavaScript syntax, too much brainpower going into trying to read Clojure :) Not because it is bad, just have not learned it
3. That is true, but now it is conceptually no different than signals/actions and for that very reason. You should look into a different file to read the state change. I think it is a good thing. State changes are often very complex, surprisingly complex. They should not be inside a component. I think a component should only be about rendering UI. State changes should be expressed by a different layer.
So what I think is interesting here is that we seem to look at the app from two completely opposite sides. I do not care about the components to understand my app, because they just express its output, the UI. My app is really the state defined and the way it changes that state. What I do care about though is having dumb components is that makes me able to do universal apps, just move my app to a new UI output like react-native etc.
It will be really interesting to see how Om Next affects the JavaScript community. We are good at getting ideas from other languages and practices, where Elm is a good example :)
Again, not stating that you are wrong about anything. It is nice to go into a component and understand how that component works. Its just in my experience really bad to use a "view" as a container for state and business logic. That said it is really important to be open minded and I hope to see us grab ideas from Om Next. Actually trying to inspire creator of Baobab to bring in some new ideas :-)
We use both; local component state as long as nobody else (might) be interested (this usually the case for generic components that are not application specific, such as page controls, checkboxes etc). But as soon as state starts to creep upward in the component tree, we move it directly to global state and store it in observable data structures (using mobservable) so that any component interested can use the data in whatever way it was delivered (through props, global state, closures, etc) and (un)subscribe automatically.
It is a global store that can be modified inside of the components safely, as if it was component's local state.
A change anywhere in the store will trigger an update event at the top of the store, notifying the rest of the app. So if you use a part of the freezer store as local state for your component, you'll get both requirements:
* Any change to the local state will rerender your component - ease of use.
* Your component's local state won't be hidden anymore. You will be able to access it from outside the component.
This is exactly what Relay is by the way. You component asks for state, and gets it from a server. The fact that it comes through props is actually just a downgrade because it means you must now treat it as some special thing, and not variables.
In the ideal world, we can write simple components that fetch state from wherever (remote, local, global). They store that state into themselves, and it "just works". They can write back that state just like how they write variables. And all of this "local" state would really be backed into a global state store invisibly.
Local state - Pros: easy to reason about, easy to use. Cons: trapped in one place, inflexible.
Global state - Pros: can be backed in various ways, easier to share. Cons: Hard to use, harder to reason about.
Local state backed to global store - Has all the pros and none of the cons. Unfortunately doesn't exist yet today.