Hacker News new | comments | ask | show | jobs | submit login

My man, a lot of the pain described in this article can be solved by Mobx: https://stackshare.io/mobx

One of our engineers at StackShare[0] suggested it and it's fantastic.

Mobx is very simple to understand and will make writing a "React" page a real joy again. Redux was way too complicated for what it gave, and just shot term after term after term at me that left me with a headache. I still don't understand Redux proper.

>Why do you have to type so much?

I know! I nope'd away from Redux because of that same reason.

But Mobx clicked for me. And if it clicked for me, it'll click for you.

Basically you have a store and you use that store anywhere in your components to share store state. When you update that store state everywhere else updates as well. Simple.

Another great reason to use React as opposed to alternatives is react-native. A _lot_ of knowledge transfer between the web and mobile with react native. It's pretty insane.

[0] - https://stackshare.io/stackshare/stackshare

I agree 100%, MobX is like a full order of magnitude performance upgrade for me over redux.

You can just think of it as "automatix redux + reselect".

People think they use redux for immutability but in my experience most people just use it for updating the view when the store changes and end up with a lot of denormalization and stale state.

With redux you derive as much state as possible which is great.

> Simple, scalable state management


It says "simple" but looks complicated. Any pointers? Is it because I don't know how decorators work it looks complicated?

MobX is _incredibly_ simple.

If you have a property you need observed - add a `@observable`.

If you have a react component you want to update automatically, add `@observer`.

Derive as much as you can using `@computed`. You can but shouldn't use `autorun` which monitors side effects.

If you're already used to Vue it's very similar except it works with React.

That's pretty much it - just clone a boilerplate - the API surface is _tiny_ and everything "just works". I have a hard time describing how stupid I felt for using Redux after playing with MobX for 10-20 minutes.

I get the feeling that the terms "easy" and "simple" are being mixed up here. MobX is a lot more complex than Redux (core), as it tries to do a lot more things that are braided together as a package. In Redux you choose to bring in that complexity (reselect, redux-saga, etc) if necessary. "Easy" is subjective, "simple" is not.

> MobX is a lot more complex than Redux (core) [...] In Redux you choose to bring in that complexity (reselect, redux-saga, etc) if necessary.

I've dug quite a bit into Redux and I don't think that's really true. In particular I don't think you "choose" to bring in that complexity. Redux is inherently complex the moment you add async actions to it, which (in my view) any real Redux app will need. Something as simple as "fetching some data when you click a button" is a surprisingly elaborate process. Similarly, trying to map a large state tree (which any real Redux app will have) to a component tree is not easy. Libraries like reselect and redux-saga (or event redux-thunk) sprung up and became essentially universal because they address the inherent complexity of Redux.

I just don't think it makes sense to tease out a small chunk of the code a Redux app needs to function and say "look, this chunk is small!"; it's true but meaningless.

Save me the Rich Hickey talk.

MobX is dead simple, it's a short write and here's how it works:

- observables: add a getter/setter pair in place of the property - when it gets modified emit an event. - observer: when an observable getter gets called inside the `render` in React - listen to future updates and re-render. - computed: do the same thing as observer - but emit the value instead of rendering.

All MobX does is change detection, it has a very low API surface, it can be implement in a lot less code (but optimizes heavily) and it is one of the simplest packages I worked with without middlewares and connectors and selectors and so on.

In Redux you have a dispatcher, actions, a reducer and so on. In MobX you just have plain JavaScript objects for state and plain functions. MobX also composes much better with things like Rx.

Redux core is like less than 60 LoC. It can't possibly be more complex.

Except it is. I have worked on a couple of react/redux production projects and they all work well, but I still think redux is way too convoluted for most use cases. Too many abstract concepts.

Also their naming of the features could have been better. For example "reducer" makes sense ONLY after you understand what's going on. It should be the other way around--the naming should be intuitive enough to actually help me understand the concept easier.

A lot of physics theories are distilled down to a single equation, but that doesn't mean it's simple concept to understand. I personally think a library with 10000 lines of code that operate using setters and getters is much more simple to understand than a library with 100 lines of code that has all these esoteric concepts.

Without the decorator sugar, the core algorithm of MobX is also 60 LOC.

The author goes through it line by line here:


It looked "magical" and tripped up my "too good to be true and I'll have problems later" sensor. Then I looked at that video and realised the idea is rather simple and brilliant.

Probably. Key things to know:

1. New JS decorator syntax

2. ES5 getters and setters

3. Observables

If you know those (and none are especially complicated), then I think the cognitive overhead of MobX is basically zero.

Ok, so I think I understand how MobX works. What I don't understand is how this is different from just having a global handler updateStore that runs a forceUpdate() on the root component. You set todo.done = true somewhere down the line and run updateStore. It will re-render everything and change wherever todo.done is used.

Mobx reminds me of Ember and bringing the Ember paradigm to react folks

Why not use Pouchdb then? Pouchdb even can synchronize itself with server DB.

The problem with the JS world.

There is a valid criticism at the core here, that the JS community jumped a bit too quick on Redux/Flux. Even the author of Redux said quite a few times now that you should not blindly use Redux, but only if you see an actual need for it.

I liked Redux when I experimented with it, but it is not a panacea, the advantages you gain are not entirely for free, and it might not be worth the boilerplate and complexity if you don't have a very complex application.

You can use React vanilla if you want, but you will spend a lot of time keeping props in sync and making sure changes are invoked up the chain.

So cool, you nailed that down vanilla - you're awesome.

Or you can just Mobx and not worry about it.

It's not like you're forced to use Mobx. Even when I worked with Windows Forms in .NET 2.0 you still had to have some way to keep values in sync, and instead of "Mobx" you had some home-grown monstrosity.

The article says use X instead of Y and there's a comment oh what about Z. lol

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact