4 ms·

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

My man, a lot of the pain described in this article can be solved by Mobx: https://stackshare.io/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 https://stackshare.io/stackshare/stackshare

inglor 10y ago
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.
dfarts 10y ago
The problem with the JS world.
- sergiotapia 10y ago
  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.
  - dfarts 10y ago
    The article says use X instead of Y and there's a comment oh what about Z. lol
- fabian2k 10y ago
  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.
Kiro 10y ago
> Simple, scalable state management https://github.com/mobxjs/mobx https://github.com/mobxjs/mobx It says "simple" but looks complicated. Any pointers? Is it because I don't know how decorators work it looks complicated?
- inglor 10y ago
  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.
  - eiriklv 10y ago
    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.
    - inglor 10y ago
      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.
doingmyting 10y ago
Any technology that toots its own horn by calling itself "simple", I don't use. This is a rule I made especially for the JS world.
lisivka 10y ago
Why not use Pouchdb then? Pouchdb even can synchronize itself with server DB.
flylib 10y ago
Mobx reminds me of Ember and bringing the Ember paradigm to react folks
Kiro 10y ago
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.

inglor 10y ago

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.

dfarts 10y ago

The problem with the JS world.

sergiotapia 10y ago
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.
- dfarts 10y ago
  The article says use X instead of Y and there's a comment oh what about Z. lol
fabian2k 10y ago
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.

Kiro 10y ago

> Simple, scalable state management https://github.com/mobxjs/mobx https://github.com/mobxjs/mobx It says "simple" but looks complicated. Any pointers? Is it because I don't know how decorators work it looks complicated?

inglor 10y ago
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.
- eiriklv 10y ago
  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.
  - inglor 10y ago
    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.

doingmyting 10y ago

Any technology that toots its own horn by calling itself "simple", I don't use. This is a rule I made especially for the JS world.

lisivka 10y ago

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

flylib 10y ago

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

Kiro 10y ago

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.