MobX – Simple, scalable state management for React
mobxjs.github.io
MobX – Simple, scalable state management for React
1–10 of 27 posts
Re: MobX – Simple, scalable state management for React
#2More in depth: https://egghead.io/courses/manage-complex-state-in-react-app...
Re: MobX – Simple, scalable state management for React
#3It was great to start with, but as the app got larger and more involved, performance started to suffer (from all the different observables and computed triggering and retrigger on a change), memory leaks started to creep in, and eventually I started noticing weird glitches where bits of the UI wouldn't by entirely in-sync. Worse, there was very little I could do to fix it, because the bug was deep in Knockout's "magic". My models had correct data, but sometimes my UI would not.
The lesson I picked up from that was that that sort of magic was bad news, and for my next major project I used React, and when I needed state management I eventually ended up with Redux. I won't lie: There's been some pain points, there's a lot less hand holding, more boilerplate, etc. But performance has been amazing and there's been no issues where something other than my poor coding has caused a bug. Redux code is very, very deterministic: You state looks like X, then you have an event Y, and now your state looks like Z. That state is fed into your component hierarchy, and DOM elements come out the end. If you don't like the result, you can quickly narrow it down to being a bug in your render methods, your reducers, or your actions. No magic.
MobX...looks great. But it looks great in the specific ways that Knockout burned me in the past. Does anyone have any input on that? If I go all-in on Redux and write a very large and interconnected app, I have confidence that:
1) Writing all the reducers and selectors will be pretty big pain
2) Once I do it it'll work just as smoothly as a hello world app will.
If I go all in on MobX, it looks like it'll be easier to write, but...how's it going to run? Saying "inspired by Knockout" gives me distinctly mixed feelings, seeing as how I started using React to get away from Knockout. :)
Re: MobX – Simple, scalable state management for React
#4It's clear what's happening, without a tons of boilerplate code, and it has some nice dev tools as well (trace element updates & events, great for debugging). It also has very useful error messages in development mode (which is a godsend).
On top of that, I think the docs are pretty good, they seem to be quite active on GitHub and, from every piece of the puzzle that comes together to make a 2016 web frontend (react, web pack, babel, flow, ui kit, etc, etc), it's given the least trouble for me so far.
Re: MobX – Simple, scalable state management for React
#5I wrote a very large app in Knockout back in the day, and ran into significant problems with Knockout's computeds and the two way data binding. It was great to start with, but as the app got larger and more involved, performance started to suffer (from all the different observables and computed triggering and retrigger on a change), memory leaks started to creep in, and eventually I started noticing weird glitches wh…
In practice it turns out to work very well for large apps and many people use it that way (https://twitter.com/_ericelliott/status/766812933804269568)
Re: MobX – Simple, scalable state management for React
#6Re: MobX – Simple, scalable state management for React
#7I wrote a very large app in Knockout back in the day, and ran into significant problems with Knockout's computeds and the two way data binding. It was great to start with, but as the app got larger and more involved, performance started to suffer (from all the different observables and computed triggering and retrigger on a change), memory leaks started to creep in, and eventually I started noticing weird glitches wh…
Things I noted:
1) Agree with your #1. It's a pain of boilerplate.
2) Agree, Redux is very easy to reason about and debug.
2) MobX was definitely much faster to develop.
3) MobX performance was better out the box. I may have done something wrong, however I have noted this with the mortgage example.
4) MobX has its own pain points when trying to build more advanced (tree) data structures. Creating a nested observable object requires creating map objects at every step of the tree. This makes using libraries such as lodash difficult.
5) I prefer the redux dev tool
6) Redux containers works well at the top level, however implementing a reusable container requires more boilerplate code. Since there is no consensus library or approach here - I implement my own solution with caution.
7) It is possible to use both redux and mobx on the same app, but you need to know what you're doing. Additionally you seem to lose some of the benefits of redux when you do this.
8) You can communicate between stores, but I feel this is a bad approach and will lead to messy code.
In the end I chose to proceed with Redux, however I think MobX implemented with proxy objects would be amazing.
I look forward to a framework that sits on the top of React and Redux designed to reduce the boilerplate. Perhaps Vue2 will be what I'm after
Re: MobX – Simple, scalable state management for React
#8Online courses: Introductoin by LearnCode.academy: https://www.youtube.com/watch?v=_q50BXqkAfI More in depth: https://egghead.io/courses/manage-complex-state-in-react-app...
Re: MobX – Simple, scalable state management for React
#9I wrote a very large app in Knockout back in the day, and ran into significant problems with Knockout's computeds and the two way data binding. It was great to start with, but as the app got larger and more involved, performance started to suffer (from all the different observables and computed triggering and retrigger on a change), memory leaks started to creep in, and eventually I started noticing weird glitches wh…
The idea is very much like knockout and meteor, but the reactivity implementation is completely different. First all it is generic and not designed for just the UI. MobX is completely glitch free and synchronous and has explicit distinction between computed values and reactions (side effects like updating the DOM). More important, MobX determines the right execution other of derivations on the fly, preventing issues…
MobX looks interesting but I am a little concerned that you are claiming it is bug-free.
Re: MobX – Simple, scalable state management for React
#10Mobx is a blessing ! I work on React only since a few months, I have a ton of subjects to learn, a ton of libraries to learn to how to use them. I really don't have time to learn a complex library like Redux. I tried, and learned its principles, but I soon saw that it would totally transform my existent codebase into a large cream cake with some boilerplate code everywhere. I come from Java world, which is often mock…
I'm not sure how Redux could be considered complex, the API is very small and the ideas are small as well. There is really not much to learn with Redux. Redux is like literally 100 lines of code if you remove comments and simple sanity checks.
Also, not sure what you mean with boilerplate? What kind of boilerplate do you have when using Redux? Would love to see an example of that.