4 ms·

I'm unconvinced by this argument. State machines don't let you change things whenever you feel like it. There are a set number of states and a bunch of predefi

I'm unconvinced by this argument. State machines don't let you change things whenever you feel like it. There are a set number of states and a bunch of predefined transitions between them. That structure is exactly what redux forces you to implement - whereas in MobX it's up to you to apply the same constraints. Redux with plain JS objects a a little messy IMO, because there aren't lots of nice & readable ways to transform objects without mutating the previous version. I use it with Immutable JS and am very happy with this approach.

saosebastiao 10y ago
> That structure is exactly what redux forces you to implement - whereas in MobX it's up to you to apply the same constraints. Redux doesn't force you to apply constraints any more than Mobx does. In fact, it's even less structured than Mobx...any component anywhere can emit any event that modifies any state. With mobx, you can only modify state that you have an actual reference to. > Redux with plain JS objects a a little messy IMO, because there aren't lots of nice & readable ways to transform objects without mutating the previous version. I use it with Immutable JS and am very happy with this approach. I agree that semantically immutable data structures are easier to comprehend and work with. But you still have to mutate state, or you don't have a UI. With immutable structures, you copy->modify->replace...with mutable structures, you mutate in place. You can't avoid mutating state with UI programming, so embracing a model that embraces intelligent manipulation of mutable state isn't an indictment, it's a tangible benefit.
aidos 10y ago
I made a poc with Redux and I felt that a) the boilerplate obscured my code b) the async story was pretty confusing and c) managing my derived / calculated properties was really hard. One thing I've discovered is that a lot of the logic is derived data in the form of pure functions. A huge amount of my codebase seems to be about managing the derived state that trigger from a core bit of state changing. Really there's actually a much smaller core set of data, and then various aggregations on top of that (with the component view tree being the final representation). I initially played with MobX a while back and had the worry that you could end up with state changes triggering off all over the place, but I don't think it needs to be like that. There's no reason you can't have core state, layers of calculated properties and a view. Having said that, it's early days, which is why I'm looking to hear real stories of where MobX hasn't worked. My approach when evaluating technology is to try to find ways in which it works poorly so that if I do pick it up I'll have an idea of the limitations (and can try to work around them). MobX does also have "strict mode" where you have to declare the transition points. I know that's not really the same as the reducer model, but it does force people to think about when state will be updated.
- lenkite 10y ago
  https://github.com/redux-observable/redux-observable https://github.com/redux-observable/redux-observable addresses your point b) and your point c) somewhat.

saosebastiao 10y ago

> That structure is exactly what redux forces you to implement - whereas in MobX it's up to you to apply the same constraints. Redux doesn't force you to apply constraints any more than Mobx does. In fact, it's even less structured than Mobx...any component anywhere can emit any event that modifies any state. With mobx, you can only modify state that you have an actual reference to. > Redux with plain JS objects a a little messy IMO, because there aren't lots of nice & readable ways to transform objects without mutating the previous version. I use it with Immutable JS and am very happy with this approach. I agree that semantically immutable data structures are easier to comprehend and work with. But you still have to mutate state, or you don't have a UI. With immutable structures, you copy->modify->replace...with mutable structures, you mutate in place. You can't avoid mutating state with UI programming, so embracing a model that embraces intelligent manipulation of mutable state isn't an indictment, it's a tangible benefit.

aidos 10y ago

I made a poc with Redux and I felt that a) the boilerplate obscured my code b) the async story was pretty confusing and c) managing my derived / calculated properties was really hard. One thing I've discovered is that a lot of the logic is derived data in the form of pure functions. A huge amount of my codebase seems to be about managing the derived state that trigger from a core bit of state changing. Really there's actually a much smaller core set of data, and then various aggregations on top of that (with the component view tree being the final representation). I initially played with MobX a while back and had the worry that you could end up with state changes triggering off all over the place, but I don't think it needs to be like that. There's no reason you can't have core state, layers of calculated properties and a view. Having said that, it's early days, which is why I'm looking to hear real stories of where MobX hasn't worked. My approach when evaluating technology is to try to find ways in which it works poorly so that if I do pick it up I'll have an idea of the limitations (and can try to work around them). MobX does also have "strict mode" where you have to declare the transition points. I know that's not really the same as the reducer model, but it does force people to think about when state will be updated.

lenkite 10y ago
https://github.com/redux-observable/redux-observable https://github.com/redux-observable/redux-observable addresses your point b) and your point c) somewhat.