Hacker Read

kuon | karma 2114 | avg karma 3.05 · 2017-01-05 22:58:08

About the "go without redux point", I've switched to MobX, and it helped me greatly for this, as I can implement proper state handling very quickly even when the project is in it's infancy. You just create a class, throw @observable in it and boom, you get everything without any boiler code.

purplerabbit | karma 540 | avg karma 2.31 · 2017-01-05 23:10:04

I second this. In my experience Mobx actually speeds up initial development. And it is easy to learn. The same cannot be said for Redux.

thomasrognon | karma 125 | avg karma 1.79 · 2017-01-06 04:54:43+00:00

I used redux for a year before switching to mobx (which I've now used for more than a year). It is easier, faster, simpler, and scales better in my experience. I can't recommend it enough.

sandGorgon | karma 11984 | avg karma 2.81 · 2017-01-06 14:10:12

why did you do this ? we are already on redux.. but have been looking at redux with some interest.

auvrw | karma 325 | avg karma 1.2 · 2017-01-06 12:35:09+00:00

mobx looks neat ... have been using alt.js as a (similar, i think?) middle of the road solution between _all_ of redux's patterns and no flux at all..

.. i'm also told that, if all you're doing is rendering templates, you might not need anything more than hyperx (a substack production).

reply

mamp | karma 410 | avg karma 2.44 · 2017-01-06 12:56:15+00:00

MobX is great to get going quickly and it has good performance. However, in my experience, with a team Redux is great because it enforces a standard approach and clear representations. Well worth the boilerplate overhead.

unsoundInput | karma 138 | avg karma 5.31 · 2017-01-06 16:08:23+00:00

I am very confused what kind of state management MobX implements, especially after reading their current README (https://github.com/mobxjs/mobx/tree/6ed404b96a8b4074a473accd...)

Is it Ember/Vue-style "mutate, observe, compute" as implied by most of their example code or Flux-style as implied by their introduction visualization (https://github.com/mobxjs/mobx/raw/6ed404b96a8b4074a473accd2...)? Do I create actions or just mutate state directly (again, visualization and some text in the readme vs examples)? How is "observer turns React (function) components into derivations of the data they render." any different from just plain React components?

MobX feels like someone tried to make an easy state management solution (obviously a great goal) and in the process just threw together whatever pattern exist out there right now. It obviously works for many people, considering how often someone comments about it on HN, but I wonder what makes those user stick with React vs a framework that completely embraces this approach like Vue or Ember.

Is it some hard requirement on React?(EDIT: Or maybe preference of JSX?)

reply

iamcasen | karma 593 | avg karma 2.19 · 2017-01-06 18:12:33

I'm surprised there is no love for nuclear-js in this thread. I personally didn't like redux's approach, but I understand where it's coming from.

Nuclear-js feels heavy-handed, and there is indeed a lot of boiler plate, but in the end the explicit organization pays off in a huge way.

What most people don't realize is that state management will get insane past a certain point. Nuclear-JS can handle a truly massive application that is very complex -- think google docs/sheets

I imagine most people aren't building something like that though, and find it too cumbersome.

reply