Comment by megalomanu | Hacker News Reader

Comment by megalomanu | Hacker News Reader

Mobx is a blessing ! I work on React only since a few months, I have a ton of subjects to learn, a ton of libraries to learn to how to use them. I really don't have time to learn a complex library like Redux. I tried, and learned its principles, but I soon saw that it would totally transform my existent codebase into a large cream cake with some boilerplate code everywhere. I come from Java world, which is often mocked (especially by the JS community ...) for its abstract-factory-factory, but Redux is not irreproachable for that ! Compared to Redux, MobX is a breath of air. It's very simple, very efficient, and contrary to Redux, not opiniated. It's easy to integrate it in an existing app. At the beginning, I only used MobX in a complex part of my app. I added a store, some instructions, and voilà. Then I added it everywhere, part by part, incrementally. Everything works, my code is simple, anybody, even a beginner, can understand it. MobX seems to be directly integrated in React.js, linked to the React core.

I haven't used Moxb but I've used Redux a lot the last 6 months, building mobile apps and also a rewrite of our frontend at Typeform.

I'm not sure how Redux could be considered complex, the API is very small and the ideas are small as well. There is really not much to learn with Redux. Redux is like literally 100 lines of code if you remove comments and simple sanity checks.

Also, not sure what you mean with boilerplate? What kind of boilerplate do you have when using Redux? Would love to see an example of that.

Personally I found that using redux for everything ends up spreading a ton of boilerplate everywhere. Action creators, reducer, the dumb component itself, the HOC.

All that adds up and is a lot of work for a simple component.

We ended up going with a hybrid setup. Our components are all dumb, and our "pages" are the only connected components. We also started using ducks[1] instead of spreading the reducer/actions everywhere whenever it makes sense.

[1] https://github.com/erikras/ducks-modular-redux

Redux isn't conceptually complex, but I found it hard to get started with. The trouble I had wasn't the ideas, which are very clear, but in trying to predict which parts (composing reducers, passing state to components) would be animated by Javascript magic, and which were plain-ol-Javascript.

I found myself straining a little to memorize code snippets to get things started.

Once up and running, it's a breeze, though of course I agree with the common sentiment that it's too easy to overuse, and native React state too easy to underuse.

It gets really hairy when you have to weave in asynchronous actions and things like react-thunk or react-saga. By the time you've wrapped your head around those concepts as well the whole React stack doesn't feel quite as much like the breath of fresh air it does when you first start using it.

For my next Resct project I intend to go as far as I can with simple container components before I start pulling in the whole Redux toolkit.

This is why Ryan Florence (react-router, React Training) just made his keynote speech at the React Rally conference about people overusing Redux and not learning or wanting to use plain old React.

In his trainings he constantly sees people trying to rush React and asking him about Redux (which he doesn't cover).

This is also a drum that Dan Abramov (who created Redux) has been beating.

It's interesting, I didn't find -thunk all that hard to grok, and in practice I was far less annoyed by that than I was by connect(). But I also found -thunk a refreshing change from what I'd been doing prior to redux (Flummox with async-await action creators).

Redux isn't complicated, it is the ecosystem around it which can be overwhelming or partly overengineered.

When you get started with React, you should use setState. You should use it until you get the feeling you really need a state management library to deal with most of the setState implementations. That removes the urge to learn another library next to React in the beginning.

Afterwards I agree: MobX is easier at the start, because it can be used similar like setState https://medium.com/@mweststrate/3-reasons-why-i-stopped-usin...

But at some point the developer team might decide to use MobX' useStrict to have more explicit actions and more predictable state changes. It removes the feeling of having two-way data binding and after all goes in the direction of the Redux constraints.

Reply on news.ycombinator.com