A Case for setState
Zack Argyle

One of the key problems I have grappled with in my previous work is dealing with actions that should modify the state of 2 separate branches of the component tree. When using explicit state setting, you have to do all kinds of contortions, passing callbacks deep into the tree where their relevance is questionable and distracting to the thing that your component is doing there. Ultimately, one ends up with spaghetti state — come back to your code in 4 months and you have no idea how it works. The design pattern redux introduces means the action triggering state updates does not need to know where the state change is happening. It also means the place where state is changed is also easily found and therefore the documentation is self-evident 4 months later. Components display stuff. This is easy to unit test. State is connected to the props very simply. There is very little room for stupid spaghetti.

For simple projects, there is no reason to use any framework at all. Just write it and yawn.

But any project with complexity will benefit from this kind of separation of concerns if you want it to be maintainable even 6 months down the road

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.