7 ms·
If you're looking for something easier to use to help you manage state in your React apps look no further than Mobx. It's pretty incredible how stupid easy it i
by sergiotapia 10y ago
If you're looking for something easier to use to help you manage state in your React apps look no further than Mobx. It's pretty incredible how stupid easy it is to use, it kind of feels like cheating.
https://stackshare.io/mobx https://stackshare.io/mobx
I've tried to use Redux a couple of times but I just spent way too much time in plumbing code. Code I really don't care about. To be frank this code looks terrible (no fault of the author):
const handlers = {
[CREATE_NOTE]: (state, action) => { ... },
// ... a thousand more of this
}
Not to mention, I never not once felt happy working with Redux. I'm all about developer UX and working with tools that feel nice to use.
With Mobx you just declare a variable as Observable, then mark your components as Observers, and voila: You have crispy, no-plumbing reactivity.
In a way it kind of feels like Meteor where you save data on the database and it replicates everywhere it's being used.
- dxhdr 10y agohttps://github.com/mobxjs/mobx/blob/gh-pages/docs/best/react.md https://github.com/mobxjs/mobx/blob/gh-pages/docs/best/react... "MobX usually reacts to exactly the things you expect it to. Which means that in 90% of your use cases mobx "just works". However, at some point you will encounter a case where it might not do what you expected. At that point it is invaluable to understand how MobX determines what to react to." I'm going to be tossing and turning tonight trying not to dream about libraries that usually work 90% of the time.
- WA 10y agoThis isn't about working only 90%. It means that it fits your current thinking to 90%. Only in 10% of your use cases do you have to dig deeper and actually understand how MobX works.
- nherment 10y agoI totally agree. When working on React, Redux drove me insane. The way it expects you to wire actions/data is completely stupid in my opinion. It took me a bit of time to fully understand MobX and I think it's still rough on the edges but its modelisation and usage make so much more sense. MobX is an elegant solution compared to Redux's brute forcing approach.
- funzofactofive 10y agoThere are several state managers on npm, some very simple and small, as an alt to redux (or even mobx)
- funzofactofive 10y agohttps://www.npmjs.com/package/tiny-state-manager https://www.npmjs.com/package/tiny-state-manager https://www.npmjs.com/package/tiny-state-manager https://www.npmjs.com/package/tiny-state-manager Maybe not for prod, but certainly great for simple uses and a quick start :)
- jbrantly 10y agoI'm eagerly awaiting mobx-state-tree. Basically the best of both worlds. https://github.com/mobxjs/mobx-state-tree https://github.com/mobxjs/mobx-state-tree
- dugmartin 10y agoMobx is really nice. For a quick and easy database for an Electron app I added a Mobx observer that persists the state to a json file which is read back at startup. It was just a few lines of code and you get seemless persistence for free. I've expanded on that idea for another Electron app I'm working on (http://www.serverwrangler.com http://www.serverwrangler.com) that encrypts the data before saving and has a database "server" in the main process so data is shared between multiple Electron windows of the same app.
- realPubkey 10y agoYou should definately look at RxDB when you need a persistent reactive store.
- vuldin 10y agoI can't agree more. After using both there is no question that, for me, mobx is better. It is more intuitive and has much less boilerplate code. I've tried to understand why redux is chosen over mobx in some projects, and at this stage I feel it is mainly just momentum and visibility/marketing.
- fiatjaf 10y agoYou see something is flawed in Redux at the point you have to pass strings (uppercase constants defined somewhere) around, import them in every file, pass them as identifiers of what you should do with each data.
- catshirt 10y agoif you use redux-actions your reducer can use an action reference directly- not its "type" string. developing this way I don't need to store references to these "constants" and they're only ever relevant when logging.
- joshwcomeau 10y agoYou don't actually have to do this if it bothers you. You can just use the strings inline, but the author (and many of those using Redux) finds it helps to reduce errors, by instantly pointing out typos. There are also patterns to reduce the import issue. For example, https://github.com/erikras/ducks-modular-redux https://github.com/erikras/ducks-modular-redux. I prefer defining my actions with my action creators in one big index, but the point is that there is absolutely a way to mitigate this concern if it bothers you :)
- fiatjaf 10y ago> You can just use the strings inline Well, that would be much worse, don't you think? My point was that having to keep identifiers to everything is silly.
- shriek 10y agoThe point of keeping identifiers is to show you the intents of an action. If any identifiers seem silly to be added then maybe they don't deserve to be going through reducers in the first place.
- rexpop 10y agoWhy is it flawed to use the module system to enforce references?
- fny 10y agoI never understood why a lot of this was never handled with metaprogramming. I feel like it might have something to do with Redux using constants and imports as a type safety hack, but all the ceremony drives me nuts. First we enumerate our actions as constants... const ADD_TODO = 'ADD_TODO' Then we need to create an "action creator" somewhere: import { ADD_TODO } from '../actionTypes' function addTodo(text) { return { type: ADD_TODO, text } } Then we need to import that action and dispatch it when we need it... import addTodo from './actions' dispatch(addTodo(text)) Now even the same nonsense for reducers...
- danielearwicker 10y agoI developed a kind of meta programming pattern and supporting library, based on Redux, called Immuto, to get absolute and complete static typing (via TypeScript) and minimal boilerplate, also referentiality and modularity (cursors that accepted actions). It was fun, but ultimately pointless, as it was never as straightforward as using the automatic observable approach that I'd learned from Knockout.js. Then I heard about MobX (which is the same ideas from KO but better implemented and without any quirky UI templating thrown in) and so now I used that. Also I use my json-mobx library to get serialisation and undo/redo. Example: https://github.com/danielearwicker/baltar https://github.com/danielearwicker/baltar
- stevejohnson 10y agoSpeaking as someone working in a large Redux codebase, I agree with you 100%. The amount of boilerplate required to do almost anything is staggering.
- acemarke 10y agoDan Abramov has said that the Redux docs were written in a deliberately verbose style to get across the ideas, and he didn't really expect people to strictly imitate that style. There's a wide variety of approaches and utilities you can use to abstract things as much as you'd like - that's entirely up to you.
- abritinthebay 10y agoI feel you're glossing over the strengths of Redux and how utterly ugly MobX code looks. Not to mention it's heavily decorator based, which makes things a _lot_ more complex and inter-dependant. No thanks.
- sergiotapia 10y agoMobx isn't ugly at all. Are you using decorators? You should. Example: import { observable } from "mobx"; export default class TodoStore { @observable todos = []; constructor(props) {} } // Elsewhere in a different file, now you just use it. import TodoStore from './stores/todos_store.js'; import { observer } from 'mobx-react'; @observer export default class Todos extends Component { constructor(props) { store = new TodoStore() } addTodo = (todo) => { store.todos.push({ id: 1, text: "Get Milk" }); } render() { return ( // Just iterate over `store.todos` ) } } As you can see you just use the variables and get stuff for free out of the box with no plumbing code except `@observable` and @observer`. What's not to love?
- abritinthebay 10y ago> What's not to love? For me? Basically all of that. Also now that code is highly dependent on the framework and tightly coupled. Observables have their place for sure, I like them as a concept actually, but for me MobX is encoding an anti-pattern I try to avoid.
- sergiotapia 10y agoBe careful you don't become an architecture astronaut though. At some point you have to stop working on plumbing and actually solve the business need. https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
- abritinthebay 10y ago
- josephorjoe 10y agoI've tried hard to like Redux as I have to work with it, but I can't. At first I was perplexed by the boilerplate and the awkward way it seemed like I had to update 5 files just to toggle a view element -- but I figured I just didn't understand yet and one day when I did it would all make sense. Well... after about a year of working with it, I'll admit I understand it and there is some sense to it, but there really is nothing elegant or likeable about it. I too have never felt happy working with Redux. I've got a side project I've been working on and was planning to use Redux since that's what I use at work, but I think I'll take this as an opportunity to try out something else.
- msoad 10y agoMy suggestion is to try Mobx and write your code in TypeScript. It's a different concept when you first look at it but then you'll see it's actually mostly the same as Redux but with less boilerplate code.
- shados 10y agoWhile it wasn't really the original point, Redux picked up at a time where Angular 1 had a near monopoly. Redux got mindshare because it was the opposite. Do away with the magic, have a predictable flow, and virtually no framework. Just a design pattern where everything is explicit. It got really popular because a lot of people want that. Typing is cheap. If a bit of boilerplate and a couple of files drastically affect your productivity, you're not solving a hard problem (and if you're not solving a hard problem, which is the common case, there are a lot of other tools better suited for it). But because it got popular, everyone jumped on the wagon, including people who were not the target audience, or were not solving problems it was a good tool for. Now, people try to force Redux into being something else, and it really, REALLY sucks at that.
- jdeal 10y agoMobX is really cool, and I wouldn't try to convince anybody not to use it if it works for them. I happen to be pretty religious about immutable data, having been bitten by problems with shared mutable state so many times. I know MobX has actions which help a lot, but I still like the core simplicity of Redux, even if it means more typing. My dream would be to have David Nolen (of ClojureScript) and Michel Weststrate (of MobX) do a panel where they discuss the essential differences and pros and cons of each approach. The philosophies seem at odds, but I think there's probably a core truth that neither side has fully reached. Also, I think the core lacking thing of Redux is that it isn't really composable like React. I'm really curious to check out https://github.com/FormidableLabs/freactal https://github.com/FormidableLabs/freactal since it aims to be a fractal (composable) alternative. (And yes, props to Elm for having a built-in composable architecture.)
- msoad 10y agoThere is no immutable state, at best we have immutable data. Benefit of immutable data is you can inspect two different states when state transitions from state A to state B. You get time travel and all that with this basic concept. MobX makes it very easy to do that inspection between states. Don't look at mutable state as evil. Redux state is mutable too.
- cel1ne 10y agoIn my opinion mutable state is most often better than immutable state. In JavaScript, that is, I have a different opinion on the JVM. The important point is that the state is _serializable_, meaning it doesn't contain side-effects. That also means NetworkRequests must be replayable. If your state is serializable, you get immutability out of the box by serializing everthing to JSON and back again.
- kabes 10y agoSince you mention Meteor. Why not just use Tracker? I feel that's such an underrated package. It's quite similar to mobx and it's been around for years. Combine it with minimongo and you've got a really flexible reactive state management.
- josemaenzo 10y agoCan we use it outside of Meteor?
- cel1ne 10y agoI write most my code in Kotlin nowadays, which can compile to JavaScript, or drive react-native on Android. It has delegated properties which are wonderful for redux-style architectures.
- jpliska 10y agoCan you share a link to an example? How do you deal with the massive size of the javascript that is generated by kotlinJS?
- cel1ne 10y agoUnfortunately not, since those apps are all business internal. On Android/react-native, the Kotlin parts runs on the JVM directly. I haven't released a KotlinJS-application to the wild yet, but I don't suppose the size is a problem after running it through webpack, uglify et. al. You are right, the runtime is rather larger though. Do you have suggestions?
- lsdafjklsd 10y agobut the OO api is a bummer, give us the Clojure Atom api!!! vamos reframe!
- lsdafjklsd 10y agobut the OO api is a bummer, give us the Clojure Atom api!!! vamos reframe!
- Kiro 10y agoMobX seems to encourage you to mutate your global state inside your components. Isn't that code smell?
- pault 10y agoI'd take any amount of boilerplate over the hand-rolled flux-ghetti code I'm dealing with now.
- jeswin 10y agoHere[1] is my take on a vastly simpler redux pattern, which hides both reducers and containers from application code, while at the same time requiring no middleware for async. It has worked wonderfully for our medium+ sized project. 1: Implementing Redux is tedious. But it doesn’t have to be. https://medium.com/@jeswin/implementing-redux-is-tedious-but-it-doesnt-have-to-be-33702a1fb1dd https://medium.com/@jeswin/implementing-redux-is-tedious-but...