Mobx: Simple, scalable state management
github.com
Mobx: Simple, scalable state management
1–10 of 30 posts
Re: Mobx: Simple, scalable state management
#2I know that a lot of people like to use different kinds of flux libraries for their React apps, with Redux having a lot of traction, but you should definitely look at Mobx.
We've introduced it to one of our project 4 months ago and our state management became as simple and easy as it should be with React. No boilerplate subscriptions, no helpers that modify normalized data, no endless re-renders on every state change and very easy to understand concept for new developers.
We literally stopped worrying about the state though it took some time to rewrite the app.
Re: Mobx: Simple, scalable state management
#3Wow, looks really interesting!
With Flux/Redux I have control over when and how data is updated, but that is not the case here. What are the performance characteristics? Is there a limit to the number of observables before performance suffers?
There is also the question of routing and history. What is the best way to use observables in a single-page app along with routing and history (i.e working back button)?
Re: Mobx: Simple, scalable state management
#4Wow, looks really interesting! With Flux/Redux I have control over when and how data is updated, but that is not the case here. What are the performance characteristics? Is there a limit to the number of observables before performance suffers? There is also the question of routing and history. What is the best way to use observables in a single-page app along with routing and history (i.e working back button)?
No difference in how you handle routing and history in a regular React app, those things are not related. Mobx (and mobx-react) just re-renders your component when data changes. You can check out performance tests here: https://www.mendix.com/tech-blog/making-react-reactive-pursu...
Re: Mobx: Simple, scalable state management
#5I've used both Redux and Mobx in two different large-scale consumer-facing apps. Mobx has proven to be a lot easier to grasp and much more flexible to different scenarios. I had to use a lot of hacks to get Redux to play nicely with different libraries since it treats JavaScript as an immutable world[0] and Mobx has greatly simplified this issue by providing tools to handle situations where objects may mutate[1][2].
0. http://stackoverflow.com/questions/32352982/how-to-put-metho...
Re: Mobx: Simple, scalable state management
#6Wow, looks really interesting! With Flux/Redux I have control over when and how data is updated, but that is not the case here. What are the performance characteristics? Is there a limit to the number of observables before performance suffers? There is also the question of routing and history. What is the best way to use observables in a single-page app along with routing and history (i.e working back button)?
Performance characteristics are that this increases expsense with the size of your data where as just re-rendering increases expense with the size of your UI. It's actually much more common to have lots of data but only render a small amount of it, so re-rendering is generally cheaper.
The size and complexity of UIs have a natural limit because of screen size and usability, but the amount of data you use to generate a UI has essentially no natural upper limit.
Pete Hunt gave a talk on exactly this almost two years ago. https://www.youtube.com/watch?v=-DX3vJiqxm4
Re: Mobx: Simple, scalable state management
#7I've used both Redux and Mobx in two different large-scale consumer-facing apps. Mobx has proven to be a lot easier to grasp and much more flexible to different scenarios. I had to use a lot of hacks to get Redux to play nicely with different libraries since it treats JavaScript as an immutable world[0] and Mobx has greatly simplified this issue by providing tools to handle situations where objects may mutate[1][2].…
I found it quite the opposite in that I grasped Redux immediately and felt lost in fog trying to work out using Mobservable
Re: Mobx: Simple, scalable state management
#8I've used both Redux and Mobx in two different large-scale consumer-facing apps. Mobx has proven to be a lot easier to grasp and much more flexible to different scenarios. I had to use a lot of hacks to get Redux to play nicely with different libraries since it treats JavaScript as an immutable world[0] and Mobx has greatly simplified this issue by providing tools to handle situations where objects may mutate[1][2].…
I found it quite the opposite in that I grasped Redux immediately and felt lost in fog trying to work out using Mobservable
I spent a lot of time trying to wrap my head around certain features of Redux. For example, all the currying used in various places (especially for middleware) makes it hard to follow what's going on. Indeed, the author points out in the guide on middleware tongue-in-cheek, "If your head boiled from reading the above section, imagine what it was like to write it." Part of my job is to figure things out and explain it to others. When I have a hard time understanding things myself, imagine how it's going to go for explaining it to someone else.
On the other hand, Mobx also did take a bit of time to figure out its API, but once it was clear, it was very straight forward how to use it and explaining it to others was also painless. No need for extraneous action-creators/reducers ceremony and no opinionated way of what kind of data I can use, or gotchas when that data is mutated.
Re: Mobx: Simple, scalable state management
#9Wow, looks really interesting! With Flux/Redux I have control over when and how data is updated, but that is not the case here. What are the performance characteristics? Is there a limit to the number of observables before performance suffers? There is also the question of routing and history. What is the best way to use observables in a single-page app along with routing and history (i.e working back button)?
Performance characteristics are that this increases expsense with the size of your data where as just re-rendering increases expense with the size of your UI. It's actually much more common to have lots of data but only render a small amount of it, so re-rendering is generally cheaper. The size and complexity of UIs have a natural limit because of screen size and usability, but the amount of data you use to generate…
That's a good point, but in Redux you subscribe to all changes in single state tree where all data lives. That means that every update of data (which has no upper limit) will cause your UI to re-render. Sure, you can implement shouldComponentUpdate, but still it will be called on every state update, plus you do can do exactly the same with mobx. The difference is that with mobx you subscribe to changes of certain data, and it happens automatically.
Re: Mobx: Simple, scalable state management
#10I took a look. This seems intriguing because it doesn't bring the whole RxJS with it to make observables work. Though I'm a bit baffled by the developer's statements about immutability of values in his SurviveJS interview [1]:
"With mutable data structures, it is trivial to guarantee that there is only one version of a certain domain object in memory."
I'd like to know how this mutable values can be tracked while immutable values can just equality check. I'm currently learning ClojureScript with few simple projects, and its immutability both pleases me and drives me crazy.
Though I can agree on his point that Flux (and Redux) do take over your application. I'd definitely like to use something else with my next React project if possible, and Mobx looks it could fit the bill.
Also, SurviveJS is a good React and Webpack book that's continuously expanded and adapted to use different libraries (like for Redux and Mobx). You should buy it!