Ask HN: How do you manage state in your React application?

Yes

apollo has a local state link (https://www.apollographql.com/docs/react/essentials/local-st...) but I did not find it useful.

Redux is fine but I guess with the new hooks functionality one can combine usereducer and contexts to create a much simpler state manager.

We use Redux at work for larger projects, React setState/Context for smaller ones, and I'm personally a huge fan of mobx-state-tree which I think is the best solution, and can be plugged into Redux if needed.

I think Redux should not be used for everything (there are libraries like Redux-Form which I think are an anti-pattern as ephemeral state like that should never go through the root reducer on every key change)

I created my own library for it.

Compared to redux it's far more simple and requires none of the boilerplate. It also allows perfect type support with typescript.

https://github.com/gunn/pure-store

Pass the things returned from useReducer() hook (state object + dispatch function) down via context. Then useContext() in child components.

Using Redux at work, looking forward to trying out the newly released React Hooks for less sophisticated needs

In the past I used Redux extensively - and I have only good things to say about Redux. I recently started using React Context and found I was much more productive, to the extent that I went back and ripped out Redux code. The new hooks thing with useContext makes using context even easier.

Learning Redux, especially the "single source of truth" thing was very helpful, but my code is now simpler, easier to understand and faster to write.

I would recommend checking out React context and hooks. I would also recommend watching the Redux videos by Dan Abramov, even if you don't use Redux.

there are a lot of options out there and this thread kind of surprised me was expecting more interesting submissions. you might want to look at the original flux:

https://github.com/facebook/flux

from facebook if you app has a lot of global state needs multiple stores can be handy.

Mobx is great too:

https://github.com/mobxjs/mobx

With the current project I am working on we actually just vanilla javascript with singeltons with subscriptions (note: I did not write this, but I think it is rxjs).

anyways someone should come along with some answers.

Redux is still the easiest and with Sagas is really cool. One start up I interviewed with was using something similar to hooks, but do not remember the name of it.

Also datomic (used by om.next in clojurescript) has some really clever optimizations and is a joy to use.

Been using MobX for about three years and I think it is wonderful. Incredibly easy to use (mark your variable as observable, modify it like you would any normal variable, and any components which use those variables in their rendering and are marked as observers automatically update), very performant out of the box (only components affected by a change re-render so no shouldComponentUpdate needed) and some excellent features like computed variables for derived values which automatically update. I really urge everyone to try it out. There is the odd time when the abstraction us a bit leaky (e.g. working with arrays is a bit different to plain JS) but with proxies in MobX 5 this is much improved.

I started out with Redux and I do think it’s worth learning - not just because it’s so widespread, but the concepts behind it are worth knowing and have influenced the way I design some stuff, but I found it really verbose and slow to work with compared to MobX (and more error prone) - there probably are libraries that help with this.

React Hooks look interesting for more simple use cases but I expect I’ll stick with MobX for the foreseeable future.

I prefer mobx to redux bc it's simpler.

Redux is the best!

Full disclosure, I’m the author of Breezy, https://github.com/jho406/Breezy. An opinionated state shape and PJAX library for Redux.

I think “how you shape your state to make it easy to reduce and share between components” is an important topic that’s taken a backseat when discussing state management tooling.

Should I repeat my backend models? Should I use a redux ORM? How much should I denormalize or normalize?

I found it much easier to just denormalize everything and shape state for presentational purposes, e.g, I have a bunch of page nodes in my redux state each with a duplicated header. If I need to make an update to the header in response to, say, a change in user email, I change each duplicated header individually.

Sounds insane but it really works for me and let’s me keep more business logic in the backend where it belongs.

http://meiosis.js.org - this is the best way to manage state

Redux. I really like keeping my state flat as the app I mainly work on has a lot of pages which use the same data. Complex component props are derived in mapStateToProps. I find reselect complex and hard to use with typescript, so I simply use memoized functions with memoize-one.

Back when Redux was fairly new, we used a "mixin" architecture with a single component refreshing the entire global state of the application. Unfortunately, this has been a horrible decision and we're currently moving towards a Redux based solution. Nonetheless, the rendering is still impressive.

https://cellcollective.org

If you don't have to support IE11, there has been a very interesting trend of JS Proxy based state managers (immer, react-easy-state, overmind, etc.). It reduces the boilerplate compared to redux while giving basically the same architecture. I have been using my own implementation, because react-easy-state did not work well with styled components (https://github.com/UgnisSoftware/lape), while I was building https://github.com/UgnisSoftware/Ugnis if you want to see this approach in use.

Been using the new Context API which has been super easy and simple to use. Though our product is not a giant SPA.

For my thick client robot management applications: Redux and an Immutable.Record. A very flat state. The only nested elements are GeoJSON features. Been doing this successfully across half a dozen deployed applications. It's really simple.

Using redux v4 with react-redux v5 for a large and complicated project. Was looking into react-redux v6 but it looks like there may be a significant performance hit (https://github.com/reduxjs/react-redux/issues/1164) so will hold off on it now.

react-apollo is very interesting to me, but my understanding is that we'd need a graphql compatible backend, which we don't have

Mobx is my go to. It's fast, and a much easier mental model to integrate. Just inject the store you want into your components

@inject

and you can call/set @observables easily.

It's much easier to onboard people. Redux is just a spaghetti mess of files upon files, trying to find the actual implementation of something. A mess.

---

I also looked into Apollo and it's obscenely good! Terrific dev UX. I'm heavily researching it currently.

I'm a Redux maintainer. I'd specifically encourage folks to take a look at our new Redux Starter Kit package [0]. It includes several utilities that add good opinionated defaults around the small Redux core to simplify common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state without writing any action creators or action types by hand.

Long-term, I want this to be the standard way that most people use Redux.

[0] https://redux-starter-kit.js.org

react-easy-state for smaller projects, apollo for bigger ones.

Just to offer a different viewpoint, my app is rather lightweight in features and a rather hierarchical structure. So I have bern able to manage just fine with props and state. It rather feels quite clean that way

At my current job we use Redux, though I wouldn't choose it myself (it had been adopted already when I joined). I think Redux is best suited to very large and complex applications, with very disciplined and skilled engineering teams, who talk to each other, refactor code, and have the time to think through things like the correct arrangement of application state, providing reusable selectors. Those teams, of course, would probably also do fine without Redux.

If you have a team that writes spaghetti code, or never has time to refactor, or doesn't have effective communication then things will be worse with Redux, because it makes the code much harder to follow (good luck stepping through things in a debugger to see how they work, for example).

This is mostly intended as a criticism of people/teams who think adopting Redux will solve problems with the messiness of their code. But I also think Redux is overly complicated and too abstract for 95% of projects. And don't get me started on Sagas...

I would recommend setState as far as you can push it, then choosing something conceptually simple like MobX (Or MobX State Tree), React Easy State, or whatever the one from Formidable Labs is. Using Redux correctly is not as simple as it seems on the surface, and it requires real thought and real understanding o t

The concept of having one store with associated actions is a great one, but Redux itself has an enormous amount of boilerplate having to do with the fact that you do all calls into your state functions as events which is completely unnecessary. Every project I’ve worked on using redux ends up having a ton of different abstractions just to reduce the redux event boilerplate overhead. I use unstated https://github.com/jamiebuilds/unstated , which gives you the beneficial central store structure without the silly event concept.