The idea of having a globally accessible Store with all the variables from the system might sound promising, but listen to me: [It's a trap!]
No doubt. This has been my biggest issue with Redux. Any tutorial pretty much says don't ever use component state. But when I couldn't come up with a good reason on why I needed to write an action creator, action, reducer, and state mapper to expand/collapse a menu, over using this.setState(), I came to the conclusion that was pretty much bs.
The article also touches on the related issue of stale state. I experienced a similar bug where modals would randomly appear. It was because the user backed out of a page with an open modal, and then revisited it, and the state was never reset, so the modal immediately opened. I understand that I need to clean up state, but in Javascript land, deconstruction/cleanup feels very unnatural.
I really think Redux is a great idea, but it has suffered from a lack of best practices and good, complex examples. The toy examples work great, but quickly break down once state gets complicated, and components become deeply nested.
Dan Abramov dropped a great piece of technology into the Javscript environment, and did that amazing time travel debug demo. The idea of an single immutable state is awesome. But he has failed to progress the project any further. In a github issue titled "Recommended usage of connect()," Dans answers a question regarding best practices with "Maybe we should just say “people have difference preferences here”."[1]
Simple things like state clean up, how best to leverage containers, what belongs in state, have all been left unanswered. Also there is a debate if data should be processed in the action creator, in middleware before the reducer, in the reducer, or with state selectors. There are so many layers to put logic, but there has never been a clear answers as to what each layer's responsibility is.
I do believe Redux's single Store solves one of the biggest React problems, which is passing props along all children components – but, as you said, I miss having good guidelines to help developers reason whether it makes sense to store all state info in a Store, or rather in a local state.
I'm sure (or at least I hope) those questions you've stated will be answered throughout time, since we're dealing with a fairly new technology and architecture.
Thanks for the comment and the GitHub issue reference! :)
2 comments
[ 3.2 ms ] story [ 13.1 ms ] threadNo doubt. This has been my biggest issue with Redux. Any tutorial pretty much says don't ever use component state. But when I couldn't come up with a good reason on why I needed to write an action creator, action, reducer, and state mapper to expand/collapse a menu, over using this.setState(), I came to the conclusion that was pretty much bs.
The article also touches on the related issue of stale state. I experienced a similar bug where modals would randomly appear. It was because the user backed out of a page with an open modal, and then revisited it, and the state was never reset, so the modal immediately opened. I understand that I need to clean up state, but in Javascript land, deconstruction/cleanup feels very unnatural.
I really think Redux is a great idea, but it has suffered from a lack of best practices and good, complex examples. The toy examples work great, but quickly break down once state gets complicated, and components become deeply nested.
Dan Abramov dropped a great piece of technology into the Javscript environment, and did that amazing time travel debug demo. The idea of an single immutable state is awesome. But he has failed to progress the project any further. In a github issue titled "Recommended usage of connect()," Dans answers a question regarding best practices with "Maybe we should just say “people have difference preferences here”."[1]
Simple things like state clean up, how best to leverage containers, what belongs in state, have all been left unanswered. Also there is a debate if data should be processed in the action creator, in middleware before the reducer, in the reducer, or with state selectors. There are so many layers to put logic, but there has never been a clear answers as to what each layer's responsibility is.
[[1]https://github.com/reactjs/redux/issues/419
I'm sure (or at least I hope) those questions you've stated will be answered throughout time, since we're dealing with a fairly new technology and architecture.
Thanks for the comment and the GitHub issue reference! :)