3 ms·
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 prop
by 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 agohttps://github.com/redux-observable/redux-observable https://github.com/redux-observable/redux-observable addresses your point b) and your point c) somewhat.