I would also argue that the loading state of an api request does not belong in the global state. This is local to a single component, putting local un-shared state in the global state makes things more complicated.
I think no more than 20-30% of state should be global: logged user and its organization, resource cache and that's pretty much it.
It's insane to have to go through all the selectors for some fairly local piece of state changed.
Partial update of state in immutable pure functional applications is pretty much open research.
We actually need machinery to deal with it, you can't just update the global state every time.
You just happen to now have the same problem again, instead of React and DOM, you reintroduced it with your entire application global state in place of the DOM, and now need some form of React to deal with it.
Perhaps the entire perspective was wrong.
Virtual Finite State machines is what I'm looking into, they contain the mutable state, the are pure in the way that state+event change state, and they allow for side effects, because without side-effects:
"Haskell is a completely useless language because in the end a program with no effects, there's no point in running it, is a useless program.
And you know, you have this black box, and you press go, and it gets hot, but there's no output.
So why did you run the program" - Simon Peyton Jones
I would also argue that the loading state of an api request does not belong in the global state. This is local to a single component, putting local un-shared state in the global state makes things more complicated.
Completely agree. I'll cover this more in the second article. Nothing belongs to global state because nothing truly is global state.
That's my main gripe with redux.
I think no more than 20-30% of state should be global: logged user and its organization, resource cache and that's pretty much it.
It's insane to have to go through all the selectors for some fairly local piece of state changed.
Partial update of state in immutable pure functional applications is pretty much open research.
We actually need machinery to deal with it, you can't just update the global state every time.
You just happen to now have the same problem again, instead of React and DOM, you reintroduced it with your entire application global state in place of the DOM, and now need some form of React to deal with it.
Perhaps the entire perspective was wrong.
Virtual Finite State machines is what I'm looking into, they contain the mutable state, the are pure in the way that state+event change state, and they allow for side effects, because without side-effects:
"Haskell is a completely useless language because in the end a program with no effects, there's no point in running it, is a useless program.
And you know, you have this black box, and you press go, and it gets hot, but there's no output.
So why did you run the program" - Simon Peyton Jones
youtube.com/watch?v=iSmkqocn0oQ