10 ms·
MobX 6
- gedy 6y agoMobX has always been such a practical and down Earth solution, I really appreciate Michel and others contributions to make React development simpler. This version seems to make same practical decisions in light of the resistance to observers and annotations ever getting approved by the standards committees.
- wetpaws 6y agoObservers are a bad pattern in a long run if you are working on large projects.
- chrstphrknwtn 6y agoI'm curious what makes it bad on large projects.
- brundolf 6y agoIn my experience with MobX, reactions that mutate observables (which triggers other reactions) can quickly get out of hand and become hard to debug if you're not careful. But doing this is also a huge code smell, and expressly stated as such in the docs, and even though it's necessary every once in a while, it's very possible to keep it under control to where it doesn't become a problem even in quite large projects.
- Gehinnn 6y agoWe put a facade on top of mobx that requires every autorun, reaction and runInAction to be named. Of course, updates outside of transactions are forbidden. This makes even complex applications debuggable!
- machiaweliczny 6y agoThat's why it should be forbidden by default. But if you use 1 way flow (events -> store -> ui) then MobX is great.
- cameldrv 6y agoIf you thought goto was bad, observers are basically a comefrom statement. You change something and literally anything can happen. Once code starts getting large, these will start causing chain reactions and the code gets hard to reason about.
- brundolf 6y agoThe goal is for nearly all of your observers to be nothing but a cache-clear on a pure function ("computed", in MobX's case). Chained reactions (reactions that trigger other reactions) are very rarely necessary and should be kept to a small enough number that you can model the entire state-graph in your head.
- spion 6y agoMobX works well when paired with a Rx-like library for the more complex cases. With that its never necessary to chain reactions.
- brundolf 6y agoMobX is possibly my favorite open-source project. The elegance with which it makes an entire problem-space just disappear, with minimal magic or surprises, with maximal performance, with a delightful user-experience, with minimal opinions or assumptions about how you use it. I have nothing but praise; React + MobX is the most productive I've ever been while working on user interfaces. On top of all that, Michael is a very reasonable and patient project leader. His documentation puts advanced concepts in plain terms, and when people file feature-requests he always displays a genuine willingness to consider their use-cases and points of view, to solve their problem if it's reasonable for the project to do so, and is never condescending even when questions or suggestions are plainly bad.
- mirthflat83 6y agoSuperb to hear that you are having maximally delightful experiences with this minimally opinionated solution-solving productive platform.
- brundolf 6y agoI think you're being sarcastic, but my praise is genuine and not exaggerated. I've seen people express similar praise for projects like Clojure; sometimes you just find something that solves your problem so perfectly that you can't help but go on about it.
- triyambakam 6y agoI have mostly found it to be a footgun and inspiration to write spaghetti. While it may have good intentions, it doesn't matter if it lets less experienced developers do absurd things that I now have to refactor. I don't think it really fits well into the React model, and while it's not only used for React, it's quite common that way
- Lazare 6y agoMy experience has been the reverse. I've found MobX code easier to maintain than equivalent Redux code, and although it's obviously subjective, I feel it is a good fit for the React model. Just noting that experiences may differ sharply. :)
- PaulHoule 6y agoA bastion of sanity against the problem of "how do I update a user interface when I know something changed?"
- spankalee 6y ago[[define]] semantics for class fields causes problems again. Sigh.
- Epskampie 6y agoI agree, super annoying, but we'll continue to have problems like these as long as transpilers keep running ahead of the official spec. In general I think the TC39 commitee has been doing a great job of moving JS forward, so I'm trusting them to have solid reasons for this call, knowing full well that it's painful in the short term.
- spion 6y agoI think this is entirely on TC39 not on transpilers, as currently there is absolutely no alternative mechanism and the resulting behavior is just surprising to many.
- spion 6y agoe.g. see also https://github.com/facebook/react-native/issues/29236 https://github.com/facebook/react-native/issues/29236
- dfee 6y agoNice work MW! I’m now left wondering what sorts of impending doom the decorator-withdrawal-situation will create for NestJS.
- ralusek 6y agoFor those that haven't tried, I recommend pairing with mobx-state-tree. https://github.com/mobxjs/mobx-state-tree https://github.com/mobxjs/mobx-state-tree
- geniium 6y agoYeah MobX State Tree does really bring Mobx to the next level. Have been using it for years and it's amazing to use.
- TN1ck 6y agoI used mobx-state-tree once with great success to implement efficient time travelling in an after effects like editor (to implement cmd+z/cmd+y). In the app, the state was updated multiple times per second and it still performed amazingly. I migrated this from mobx to mobx-state-tree and as both libraries work together seamlessly, the migration was super straight forward.
- swalsh 6y agoYou will have to take my decorators from my cold dead hands. I'm not upgrading.
- gedy 6y agoIt still supports decorators: https://mobx.js.org/enabling-decorators.html https://mobx.js.org/enabling-decorators.html
- Epskampie 6y agoHaha, I had the same reaction when I read the first heading. Then I read on and was so relieved that they are still supported. Such a rollercoaster.
- rezokun 6y agoYou still needed override constructor with makeObservable(this). This is too far from the grace of decorators. It make me sad.
- deleted 6y ago[deleted]
- kilroy_jones 6y agoAs someone who tried react + redux and then recently moved to svelte because the way things were done just made sense, how does mobx compare?
- bestest 6y agoIMO You don't need mobx if you're using svelte. Use svelte stores.
- nsonha 6y agobut then you have domain code that depends on a view library, which defeats the whole point of having a store.
- machiaweliczny 6y agoNot used Svelte but knowing how it works I guess MobX is simpler to debug. It has synchronous updates, so debugging is easy by just followig stacktrace. Not sure if Svelte is easily debuggable in contrast as it's compiled.
- etaioinshrdlu 6y agoAny opinions of this library? https://github.com/RisingStack/react-easy-state https://github.com/RisingStack/react-easy-state It looks like a slimmer version of MobX
- gedy 6y agoSeems mainly like an alternative to using class-based stores, which I guess gets under some people's skin.
- mmczaplinski 6y agoIt's great! In terms of concepts it's very similar to MobX but the API is minimal because it's focused on react only. We're using react-easy-state in the Frontity framework https://github.com/frontity/frontity/ https://github.com/frontity/frontity/ and very happy with it. (shameless plug warning) I've written about principles behind react-easy-state and MobX here: https://czaplinski.io/blog/make-your-own-mobx/ https://czaplinski.io/blog/make-your-own-mobx/
- vga805 6y agoMichel's immutability library immer is also awesome. I loved reading his post[1] about how it worked and digging through the source code. The JS community is lucky to have him and people like him. [1]: https://hackernoon.com/introducing-immer-immutability-the-easy-way-9d73d8f71cb3 https://hackernoon.com/introducing-immer-immutability-the-ea...
- shermanmccoy 6y agoSo mobx is basically global state, and an efficient change tracking algo that decides which parts of the tree need to be re-rendered. I've found using React context for state, and judicious usage of useMemo has been enough for me to be able to drop mobx or its kin, even on larger sized projects. Libraries like mobx and redux implicitly promote a massive singleton state object. I think web applications are easier to maintain if we make every effort to minimise global state. If some component way down on the left hand side of the tree needs to get something to a component at say the top RHS of the tree, I will consider refactoring, rather than add another property to MassiveStateObject. Why? Because when you come back to look at MassiveStateObject in two years the implicit coupling between the two components above will not be clear.
- andy_ppp 6y agoWhat do you do with state that needs to be global, or state that bits of start needing to be available in many components for example current username or permissions etc?
- shermanmccoy 6y agoThis is not a religious stand against all global state. Username, permissions fine to be global, this is very easy for someone new to your code to grok. I put them in the top React context, then just useReducer where I need to. Don't need to pass down through props to every component anymore, thanks to React context and useReducer. Although I was thinking if you wanted to be a religious zealot about not coding any of your own global state you could use the browser session API.
- Cthulhu_ 6y agoReact Context is the use case for that one.
- sbergot 6y agoI have come mostly to the same conclusion. UI specific state (eg a flag to store whether the left panel is folded) should be as local as possible. When you have some functional data (the lisk of tasks in a todo app) then putting that in the React context and injecting it in the UI blocks that need it is the simplest way as long the injection part is well separated (using something like unstated.next). There is some grey area between the two but with this methodology I have never felt the need to use redux or mobx again. The last time I had to use mobx I was bitten by the rough edges of the decorators.
- geniium 6y agoGreat work MW! Happy to follow mobx's growth.
- tekkk 6y agoHah, Michel got me at the end with the plot twist. If I could add a feature to MobX I would add a built-in easy way for serializing and deserializing state to local/sessionStorage without having to reach out for 3rd party library (which aren't even that good). I think that functionality is very vital for any web app. After that, I guess my biggest issue has been the injection of stores into other stores. It feels a bit dirty and can get messy. Maybe if instead of injection, MobX could offer a context based solution. And then nudge people to build their stores around specific API route/data to make them composable and smaller than the gigantic stores they sometimes come to be. Then you could easily separate the part of the store that is about how to fetch/send data to the API and the part that formats/modifies the data for the UI. I don't know, maybe that could work. Love MobX either way and hope they keep up the good work!
- sktrdie 6y agoTo some people comparing mobx to react saying that "i just ditched mobx because react does the same thing" I don't believe this is true. Apart from the seperation-of-concerns benefit mobx is different in the sense that it works with observables whereas react works with diffing tree branches. In other words react needs to work with DOM diffing and virtual dom whereas mobx and observables are granular & directly manipulate the values. This gives mobx in my opinion lots of benefits that are not so apparent in react. Mainly the benefit of performance where a computed property only reruns if any of its dependencies change whereas react updates when any of its props change, even if the prop wasn't used! A simple example is imagine in react: props => if (props.a) bar() else if (props.b) baz() React doesn't care about a nor b and reruns this code whenever props changes. In mobx (and other observable based systems) if the above computed function runs with prop.a equal to true will make mobx know that "a" needs to be tracked and mobx doesn't yet know about "b" (because that branch has never been evaluated) hence doesn't rerun if b changes. This kind of reactive granularity is what sets the two apart imho. solidjs [1] is a framework that works like mobx but for components; hence seems to be the best combination of mobx + react using observables (without virtual dom diffing) 1. https://github.com/ryansolid/solid https://github.com/ryansolid/solid
- tomduncalf 6y agoI think MobX is amazing for many reasons, but primarily because it makes my life building React and React Native apps so much simpler than the alternatives (I guess I am mainly thinking Redux here as it's the only one I've had significant experience with). Sure, there are a few gotchas (less so with Proxy object in v5, but there are still some) and you still have to pay some attention to avoiding performance issues, but I think this is true of any alternatives too, and MobX makes 95% of standard React-stateful-app-type dev so easy that I don't mind if there is the odd time where I need to debug something. I think pretty much everyone I've introduced to it has found the same. As others have alluded to, I feel like often solutions people propose in the world of JS dev (and I'm sure elsewhere) can be overly fussy and complicated, just to achieve some notion of "purity" or whatever. MobX is a pragmatic solution and that aligns with the pragmatic way I generally like to work, so I'm happy to trade off some "magic" for a great developer experience, and I'd really recommend everyone try it at least once!
- Kiro 6y agoIt was a long time ago I built anything with React but I used to use MobX mostly because of the inject function, to be able to access the global store from any component without prop drilling. I don't see much emphasis on that anymore though. Has React incorporated a native function for that? Is it the context API? Edit: What I don't understand with the context API is that it looks like I need to access the instantiated context externally in every component, while MobX injected it through the component tree automatically.
- nsonha 6y agoyeah I don't understand why the react team made such an API. It's literally service locator an anti-pattern. I started to think maybe it's best not to use mobx nor react for dependency injection and usehigher order functions/components in a poor man's DI manner is the most sustainable way forward. Because you can inverse control everything not just UIs/observables. Or use a separate lib like inversify or aurelia/dependency-injection