[matmo]

Slightly off topic, but how do people manage state that aren't using Redux? When you google "redux alternatives", you typically get results for different flavors or variants of redux. But are there other fundamentally different paradigms for managing state? I love Redux, but I'm really curious what else is out.

Also, the optimistic updates with rollbacks in this implementation is pretty neat.

[jasdeepsingh]

I've been using Mobx very successfully on many of my projects now (both React & React Native). I'll prefer Mobx any day over Redux, just due to it's sheer simplicity and ease of use. Read: No need to burden your brain with the cognitive load of actions, reducers, dispatching actions, selectors etc.

Mobx v/s Redux does kick off the OOP v/s Functional debate, but as a developer my productivity and effectiveness is measured in terms of my ability to ship software not in terms of my programming style, and it's my personal belief that Mobx does make me more productive as compared to Redux.

For developers new to the whole Flux/Redux/Mobx/State Management world, I highly suggest to give Mobx a try.

[timdorr]

Maintainer of Redux here.

I concur with giving Mobx a try. I'm using it at least one product so far and it's been working out great.

One thing I will say is that because your subscriptions are set up implicitly, it's easy to have things misbehave in unexpected ways. For instance, if you update multiple observable properties in a single function, it will fire off observers multiple times. That could put you into an unexpected state and cause some errors.

Luckily, almost every time I've run into this kind of issue, I've discovered there's an API to cover that case (runInAction in the previous example's case). And they APIs themselves are really neat and fun to work with. `when` and `observable.array`'s extensions are some of my favorites.

[Kiro]

Do you pass the MobX stores down to every child component as props or do you use @inject? I started with the former but all of a sudden all my components had all these "default" props that cluttered things up. @inject seems great but the documentation doesn't push it enough to make me believe it's best practice.

[rawrmaan]

Neither. Just import a singleton root store and reference it directly.

[hesarenu]

I was using global stores but recently moved to @inject. I needed a way to reset my stores on logout. Hence now i create a root store and initialize rest of the stores.

[diehell]

Can you suggest a good MobX guide/tutorial to follow or a place that keeps MobX resources such as acemarke redux lists?

[capocannoniere]

You might not need Redux, written by the author of Redux: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

[bryanlarsen]

MobX is quite popular, and I wouldn't call it a variant of redux.

Also, just storing state in your higher level components can work for much more complicated apps than many think.

[mercer]

I've done the latter and even though it's possible, it gets tedious/unproductive pretty quickly.

To elaborate: in 'response' to the webdev tendency I have to use the latest and greatest, and the HN articles about this phenomenon, I've done a few React projects with a conservative mindset.

React-router I don't miss too much for much of it. I could also do without a bunch of ES6/7 features, TypeScript, and so on. But with each of these projects I wish I'd used Redux, MobX, Baobab, and so on instead of the 'vanilla' approach of keeping state in my higher level components.

tl;dr: if you're gonna be conservative, leave state management as the last thing you 'conserve' on.

[samsonradu]

This is so true. Just apply the Redux idea of smart/dumb components but without actually using Redux. Higher level component(s) becomes smart and handles the state changes while passing down only properties to children.

Usually I start an app like this and when things get really complicated I add Redux and refactor the state management out of my top component.

MobX looks interesting, however didn't get to try it out yet, only briefly looked over it. I find it a bit annoying that they introduce even more syntax overloading - annotations - as if ES6/7/JSX is not enough already. Will give it a try on a pet project soon.

[charrondev]

To be fair they give many examples of using mobx without decorators. I use them because they're baked into typescript, but I wouldn't use the Babel plugin, it seems less mature.

[RussianCow]

It's also quite easy to roll your own solution. I used to do this before I heard about Redux, and the whole library was ~100 lines I think (not including tests). My implementation exposed a store and allowed you to subscribe to "events" on it (postAdded, etc). It ended up working similarly to Redux, but without the reducers (you would just handle the event in-place).

That said, these days I would never use anything but Redux. MobX is gaining traction as a viable alternative, but I just love having all possible mutations spelled out explicitly.

[enobrev]

I've been using baobab[1] which is:

> a JavaScript persistent and immutable (at least by default) data tree supporting cursors and enabling developers to easily navigate and monitor nested data through events.

It's a fairly simple library to read and understand and it's well written. I have a couple decent sized SPAs working on top of it, and I store the full data tree using localForage for offline use.

1: https://github.com/Yomguithereal/baobab

[mercer]

I've had good experiences with Baobab. The main reason I lean toward Redux is that I want my clients' product to be as 'standardized' as possible. While this is difficult in the JS world, React and Redux fit the bill (or are close to it).

[egeozcan]

I also like Baobab. Way easier to debug when things go wrong and it works very reliably so you very rarely need to do that.

[tcoff91]

I have no experience with either (I write library code, not app code) but I see MobX mentioned here frequently.

Here is a comparison.

https://www.robinwieruch.de/redux-mobx-confusion/

[weavie]

Not a strict replacement, but I am really enjoying Elm.

The architecture is very similar - I think it was the inspiration behind Redux. You get to use a more succinct syntax and there is a compiler underneath it that supports the whole process. I have only recently started with it, bit I am finding the adage that 'if it compiles it will work' is proving remarkably accurate.

[happyslobro]

I just came across Vue.js the other day, while exploring options for quickly banging out small tools. Getting tired of the clutter in a full-featured React project.

It offers more than one strategy for managing state; there is simple two way binding between a JS object and the DOM, there is the Elm-inspired vuex, and also it can integrate with Redux. http://vuejs.org/v2/guide/state-management.html

[losteric]

Flux is a standard idea in the React world... I don't know that there are any "fundamentally different paradigms" for managing state in React.

Before Redux came out, I built my own state management system around Backbone. I recommend using Redux.

[fiatjaf]

I'm doing well with storing state in multiple nested components, each state in the component it "belongs" to.

This approach matches well with GraphQL (without Relay -- but with Relay I imagine it would fit even better).

[andreasklinger]

Since we have been using graphql and apollo-client i personally havent had a moment where we really missed redux[1]

[1]: technically apollo client uses redux internally but they keep it nicely wrapped for you

[maaaats]

A huge, global, shared state makes it much harder to have an arbitrary number of a component, compared to each instance of the component holding its own state.

It's also a lot of boilerplate when you just want to add a simple toggle to some component.

[ojr]

its better to search for "flux alternatives" since flux was the earliest react state management library

[poorman]

Use Mobx if you're one of these people who like doing less work and writing less code to achieve the same end result as Redux.