HN Explorer

Ask HN: What are the best alternatives to MobX for front-end state management?

2 points by sheerun ↗ HN
I left Redux camp the year it was created due to high complexity of apps created with it, and switched to MobX which employs more mutable/reactive approach, which I found quite fast to use and surprisingly manageable.

I wonder if there exist now better alternatives? What do you recommend?

6 comments

[ 1.7 ms ] story [ 22.1 ms ] thread
solardev
For simpler to moderate complexity, you might be able to get away with just the built-in useState and useContext hooks together.

You can wrap your whole app in a context provider, and/or combine it with state trees that only certain features or components or users need. Then any child within any tree can pull from the contexts.

It's up to you whether you want to use a reducer like pattern, or make the setter itself available in the context so any consumer can mutate state, or pass along a helper function that sets state as an abstraction.

Any way you do it, it will be far easier to use than the nightmare that is Redux. It might be more disorganized, with a lot of separate state hooks, but each one can be relatively modular. Overall I found it waaaaaay easier than Redux.

acemarke
Please note that "modern Redux" code is very different than what most older tutorials show. We've introduced newer APIs like Redux Toolkit, which is a set of utilities that simplify the most common Redux tasks, and the React-Redux hooks API, which is generally easier to use than the traditional connect API.

I strongly recommend reading through the "Redux Essentials" tutorial [0] in the Redux docs, which has been specifically designed to show "how to use Redux, the right way" with our recommended practices

The older patterns shown in almost all other tutorials on the internet are still valid, but not how we recommend writing Redux code today.

You should also read through the Redux "Style Guide" docs page, which explains our recommended patterns and best practices. Following those will result in better and more maintainable Redux apps.

Redux isn't the right tool for all use cases, and we don't expect everyone to like Redux :) But writing Redux code today with Redux Toolkit and React-Redux hooks is drastically simpler than the legacy-style patterns were a few years ago, and we routinely get positive feedback from folks who hated Redux before and now love using RTK.

It's also worth noting that there's significant technical differences in how Context + `useReducer` work vs how (React-)Redux works, and that affects what kinds of tasks they're suitable for. I covered those in extensive detail in a post [2].

[0] https://redux.js.org/tutorials/essentials/part-1-overview-co...

[1] https://redux.js.org/style-guide/

[2] https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

solardev
I wasn't aware that your syntax has changed, thanks for the heads-up! I inherited an older codebase and found Redux to be the single most complicated part of a relatively straightforward app, and was turned off by what seemed like needless overengineering for relatively simple use cases. I could see the power behind Redux and ReactJS but it was frankly overkill for what we needed.

I will definitely check out your links when I get back to work next week. Thank you for sharing!

matthewwolfe
My favorite approach is Zustand, which is a simplistic object with data and functions to update that data, combined with react-query for doing a lot of the data fetching. Zustand is super simple and based around hooks, and I find that with a data fetching library that handles caching, I have a lot less “global” state than in the past. IMO for even relatively complex apps, having a ton of global state is not great, and breaking things down into specific contexts that are each separate hooks is great. I think Redux’s Toolkit or whatever it’s called works similarly.