4 ms·
Personally I was dumbfounded by complexity of doing async things in redux. Libraries like redux-thunk, redux-sage, redux-observable should not exist. The amount
by wickoff 8y ago
Personally I was dumbfounded by complexity of doing async things in redux. Libraries like redux-thunk, redux-sage, redux-observable should not exist. The amount of boilerplate required was incredible and meaningful typescript support was very difficult to achieve.
Then I tried mobx, I was able to write a small app after 15 minutes of reading the docs and now I love react.
- supermw 8y agoWith context api and hooks you don't need redux or mobx. Not that either one was really all that necessary in the first place anyway.
- _coveredInBees 8y agoI've still found the concept of computed properties in mobx to be extremely useful (and I say this as someone who relies on regular React + SetState 90% of the times). MobX encourages you to think about representing your state in the minimal possible representation and to heavily use computed properties that depend on this smallest, irreducible state representation for everything else. Switching to this mindset makes developing more complex components (especially UI/forms) a breeze. I also find MobX to be great for async things and much easier to handle than via setState. Using setState alone in these types of complex components ends up being really tedious and prone to errors (largely driven by the async nature of setState updates).
- gedy 8y agoMy experience as well, MobX saved React for me, and I did a 180 from hating it to loving it.
- k__ 8y agoFor me, there wasn't even an alternative library needed. I mostly use setState nowadays and it's enough.
- _coveredInBees 8y agoYup, MobX has made developing more complex React components / UIs a sane endeavor once more. Every time I use MobX, I think to myself that it can't possibly be this simple...then run the code, and pick up my jaw from the floor because everything just worked the way you intuitively thought it should. Meanwhile, relying on setState alone for complex components ends up being very error prone and tedious. I still rarely use MobX for global state because I prefer the original appeal of React in terms of making modular, reusable components, but I often use MobX as the state mechanism for my more complex components and bypass having to rely on setState altogether for those components.