<story><title>Redux – Not Dead Yet</title><url>http://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/</url></story><parent_chain></parent_chain><comment><author>k__</author><text>Redux and MobX are overkill.&lt;p&gt;What most people want is an easy way to pass down state to nested components, but the context API is a bit verbose and otherwise you end up with the props-drilling problem, passing and passing and passing.&lt;p&gt;Problem is, Redux and MobX solve far more than this problem and in the end you are stuck with all the complexity they add, even if you don&amp;#x27;t need the other benefits they bring.&lt;p&gt;In 80% of all apps you don&amp;#x27;t need much state. They don&amp;#x27;t have deeply nested components so you can simply store the state in your root components (Screen&amp;#x2F;Page) via setState and pass everything down via props.&lt;p&gt;If you end up with deeply nested probs, use &amp;quot;unstated&amp;quot;, it adds a bit better usability to the context API and lets you avoid the props-drilling problem. You basically get something like the &amp;quot;connect&amp;quot; from Redux, without the rest Redux would require.&lt;p&gt;If you somehow end up with an app that fits in the 1% who need fully predictable control over their global state, go for Redux.&lt;p&gt;React is the simplest framework I&amp;#x27;ve ever seen, sadly Redux and co made it much more complex than needed to be, which drove many people away from it.</text></comment>
<story><title>Redux – Not Dead Yet</title><url>http://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/</url></story><parent_chain></parent_chain><comment><author>ralusek</author><text>I&amp;#x27;ve been using mobx-state-tree for the latest couple of projects after Redux. I like them both, but I prefer mobx-state-tree for a handful of reasons.&lt;p&gt;1.) There is an immutable data store with action-driven changelog, just like Redux.&lt;p&gt;2.) The immutability of the data store is baked in and enforced. The necessity to provide changes to the data store within an action is baked in and enforced.&lt;p&gt;3.) Having actions baked in as methods rather than having to create &amp;quot;action creators which in turn dispatch actions&amp;quot; is a nice reduction in boilerplate.&lt;p&gt;4.) Being able to add action listeners AND state listeners are baked in, and can be done at any level of the state&amp;#x27;s depth. To watch state changes in redux, for global changes not related to a particular component, I had to write:
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;ralusek&amp;#x2F;redux-store-watch&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;ralusek&amp;#x2F;redux-store-watch&lt;/a&gt;&lt;p&gt;5.) Mobx&amp;#x27;s observers on react render methods makes the renders far more efficient than what could be achieved with react-redux easily, without really ensuring that the props being passed in are as granular as necessary or shouldComponentUpdate is correctly identifying state changes. In mobx, the most granular access of the lowest level state can be detected within a render method, and only when that very specific value is replaced is the component rendered.&lt;p&gt;6.) Computed values on mobx-state-tree are baked in without the need for something like reselect&lt;p&gt;I like Redux, I enjoy working on projects that use it, but I think that I think I&amp;#x27;d have to admit that I prefer mobx-state-tree.</text></comment>