DEV Community

Can React state management get any simpler than this?

Arnel Enero on March 14, 2021

I'm one that loves simplicity in things. So despite the plethora of state management libraries for React, I have always wondered what the absolute ...

Read full post

Ivan Jeremic • Mar 14 '21

Recoil is as simple and more powerful

Arnel Enero • Mar 20 '21 • Edited

I beg to disagree that Recoil is "as simple", but simplicity wasn't the main objective of Recoil in the first place. Having said that, Recoil is excellent at its intended applications. I wouldn't go around telling everyone to use Recoil for everything, though.

But I'd like to reiterate, in case someone did not care to read the article... this is NOT about being the "best" library. Open source is NOT a popularity contest—it's about offering something that might be useful to somebody out there, for their specific needs.

And a wise man told me that a smart developer does not rely solely on one philosophy/pattern/library, but knows which one to use depending on the task at hand.

Brian McBride • Mar 17 '21

Recoil is alpha, and (like typical facebook) ignores what is already out in the open source. So instead of building on something, they add more options that just duplicate efforts.

If you want what recoil does, Hookstate.js is basically the same thing.

I really like what Recoil is doing, but that is because I was using Hookstate before Recoil was a thing. Atomic updates. I think over the years I've gotten severe facebook fatigure as a developer. I would seriously prefer if they uplifted existing projects instead of hyping their own replicated efforts.

Ivan Jeremic • Mar 19 '21

True but you need to understand that facebook can't use some open source package for the intern products where they depend on

Brian McBride • Mar 21 '21

What is "some"?

I do not know Facebook internal policies, so I don't know. That sounds like a weak excuse though. I can understand if you use a lib that is small or unmaintained that it is better to use the inspiration there and create your own.

If it is a company policy, I still maintain the same position. It is a choice to fragment the community. Take Netflix, they are a good example of a company that improves existing libs through contributions while releasing their own projects to fill gaps. They have depreciated their own libs in preference to a newer/better open-source lib.

While I do appreciate everyone's contribution to open-source, if a project is active - make it better. Don't replicate the efforts and fragment the community. We just have too much of that in the JS community.

Eric Bishard • Mar 15 '21 • Edited

I don't see it being an alternative to what's out there, but it's still a cool project. My suggestion is to ignore others and keep building it for your needs and cases. Focus on how it could do things better than the alternatives and worse case you just get some additional library experience under your belt? I love shall projects like this because as someone who is interested in building tools and libraries it's interesting to see other libs, modules, etc... In their initial project state. Thanks for sharing

Anton Melnyk • Mar 15 '21 • Edited

The state manager is not about being simplest, it's about being scalable and having good devtools. Nothing better than Redux in that sense.

Your state manager is good only for increment-decrement examples.

Vladimir • Mar 15 '21

In most of the cases Redux is not needed anymore, unless the application is really huge. Not just a simple crm but a large application with huge amount of logic. Otherwise, it is simpler to use things like apollo (if you have GraphQL), react-query, Recoil or Jotai. Or just write custom hooks. Redux is too complex with a need to create action creators, actions, reducers, then connect them to store. If you need to affect different parts of the store it becomes too sophisticated.
The combination of Redux and redux-observable looks impossible for junior developers. It is powerful but so overcomplicated.

Mark Erikson • Mar 16 '21

FWIW, Redux is still used by about 50% of React apps, and is the most widely used state management tool for React apps by a large margin.

You should take time to consider what problems you're actually trying to solve, and choose tools that actually solve the problems you're dealing with.

Having said that, note that we definitely do not recommend Redux-Observable as a default approach, specifically because it does add a lot of extra complication and most Redux apps don't need it - that's why we recommend thunks as the default, and Redux Toolkit includes thunks out of the box.

Vladimir • Mar 16 '21

You should take time to consider what problems you're actually trying to solve, and choose tools that actually solve the problems you're dealing with.

That's what I'm saying. Use the right tool. Before using Redux make sure you really need it.

My very rough estimates of React ecosystem state management market share are

So these are just some random statistics from some random guy on the internet. Not saying he is not right though.

Most devs still think that Redux is the only state management library and pick it just because they think so and don't want to learn new technologies. I talked to my colleagues and they simply don't want to consider using other libraries because they believe "Redux is Redux and other libraries are meh". They even didn't try those libraries. Some React devs still use class components over functional with hooks because:

projects are legacy and nobody is going to refactor them
devs keep classes on purpose because they prefer them

Coming back to my original idea. Use the right tool and be up-to-date with modern technologies.

Mark Erikson • Mar 16 '21

FWIW, I'm the primary Redux maintainer. So, sure, feel free to take my comments with a grain of salt, but A) I happen to be an expert on this topic, B) I spend most of my time answering questions about when it makes sense to use Redux, and C) I'm definitely not just "a random guy on the internet" :)

I've established a pretty solid track record of being straightforward and unbiased in my evaluations and responses:

twitter.com/tannerlinsley/status/1...

Mark is a breath of fresh air, right?! He'll forever be at the top of my list for people that I trust to always deliver an objective take on something, regardless of stake or emotion.

Vladimir • Mar 16 '21

Look, I didn't want to offend you and I partially share your opinion. I'm just saying that often Redux is popular because devs don't want to consider any changes in their existing apps and don't want to try new tools in their new projects.

Recently, I have been working on a project that uses Redux but it is just about keeping fetched data. Yes, it is a lot of data but Redux is not needed for that.

Even when it is needed to store some state maybe a custom hook is enough. Tools like Recoil and Jotai (or Xstate if your choice is state machines) can keep the state and even transform it (hello Reselect).

Coming back to my point:

Use the right tool. Before using Redux make sure you really need it.

Darlington Okorie • Mar 16 '21

I think you're very right. As soon as one becomes a react developer, the very next expectation everyone seems to have of you is that you must understand and use redux. Obviously, redux isn't the only state management tool out there. There are easier and less complex tools out there. Once you get in that for most of your projects you get to use any of the options, like Recoil, useContext and so many others, its like a brush of possibilities.

OliverRadini • Mar 17 '21

To provide some additional context (no pun intended) to Vladamir's comments...

I'm sure some developers are still using Redux because they "don't want to consider any changes in their existing apps and don't want to try new tools in their new projects." Familiarity is an advantage but ought to be weighed against the benefits which alternatives would bring. Sensible developers won't only use Redux because it's familiar, but novelty should not be the only reason to switch.

I'm still someone who uses Redux because I've not yet tried a state management library which provides enough benefit to justify the switch. If I want to tell the people that I work with that we're making the switch away from Redux, I'll be talking to smart people, and they'll rightly want to know why it is that we're making this switch. Right now I don't feel like I could provide an adequately watertight answer.

For all the same reasons, if someone already knows a library like Recoil, they are right to consider why they would switch to Redux, when they know a perfectly good solution to the same problem.

sefrem • Mar 18 '21

Every time i work with Mobx i'm so happy about how easy and intuitive it is. Worked with Redux and Effector, but Mobx nails it for me.

Ivan Jeremic • Mar 15 '21 • Edited

You clearly are in the Redux fancamp and it is the only thing you know... Redux is not even needed anymore

Smitter • Mar 16 '21

Redux is not needed any but it still has some tiny advantages such as performance optimization, for instance when compared to the context API in large applications

Ivan Jeremic • Mar 16 '21

I would also never use Context alone for big apps but instead Recoil over Redux

Nikola Stojaković • Mar 15 '21

I'm not in a Redux fancamp but Anton is right - ecosystem matters. That's the reason why some technologies are still used so much despite their flaws (I'm not saying this for Redux though).

OliverRadini • Mar 15 '21

Just to provide a contrast to some of the other comments on this comment, Redux is not complex in the slightest but it often requires a certain amount of boilerplate. It's a great option, but there are also a range of other equally good options.

shayneoneill • Mar 19 '21

"The state manager is not about being simplest, it's about being scalable and having good devtools"

I long ago realised the quest for scaleability is death to so many start ups.

You have to move fast and break things, and for god sake ship. I've seen so many good startups die to giant complexity balls bourne out of "Well what happpens when we have 20 million customers". Cool eggs, but focus on getting A customer first, because for every month your bizarely overcomplicated serverless nosql redux firebase hellmachine remains in development hell, the less enthusiastic investors become about funneling more junk money into your scheme, and then blam out of the blue someone with a simpler but functional product hits the market and eats your market becore your even laiunched. Game over.

Simplicity , is everything

Arnel Enero • Mar 19 '21 • Edited

I completely agree. In the highly competitive industry today, ship fast is the goal. I would bet, if we look at the source code of the early versions of those highly successful apps out there, the perfectionists among us would have a lot of negative things to say about them. But at the end of the day, those apps have beaten the hell out of over-engineered apps that just took too long to launch.

I like your point about "before even worrying about being able to serve millions of customers, focus on getting that first customer first" 😀. Although to be fair to the original comment, "scalable" in this context is probably referring to scaling with the growing feature set of the web app. But your idea still translates well to this context—"before worrying about delivering lots of features, focus on shipping out a minimum viable product first with one killer feature".

Arnel Enero • Mar 20 '21 • Edited

Saying that something is the best for everything would yield nothing but an unproductive debate. There is no such thing as one-size-fits-all in libraries, otherwise everybody would just use Redux for everything. Even the author of Redux himself does not recommend that.

Someone out there could be searching for the "simplest" instead of the "best", and there's nothing wrong with that.

Trashing other libraries in favor of your own favorite is not exactly helping anyone. I hope you actually looked at the library first before concluding that it is only "good for increment-decrement examples", but thanks for your feedback in any case.

robvirtuoso • Mar 29 '21

What's all this commotion lol. Even the Redux guy is here.

Anton Melnyk • Mar 30 '21

Day is not a day without state management drama!

robvirtuoso • Apr 1 '21

Nah, a good developer can write great code even with the most rudimentary library. There's no need to have "camps" in this petty topic. Relying too much on "tools" is just being weak. lol.

BennoDev • Jun 2 '21 • Edited

Yes, sure, stability/scalability trumps simplicity,
but whats about a simple AND scalable state management approach?
SimpleR State is a singleton state management approach,
and it's (in my opinion) pretty simple, scalable, and maintainable.
I have created a State Manager (AgileTs) with a similar concept,
and as far as I can tell, it is extremely scalable if used correctly.

I've created a Style Guide for large applications using such a singleton State Management approach:
agile-ts.org/docs/style-guide#-ins...

Smitter • Mar 16 '21

I found this, savage

Chad Adams • Mar 15 '21

Zustand?

Poorshad Shaddel • Mar 15 '21

An awesome library that supports async actions :)

ncpa0cpl • Mar 15 '21 • Edited

It is very unclear that "increment" and "decrement" function are in any way related to the "count" state, I'd imagine maintaining code written with this library would not be a pleasant experience, especially if it was a code written by someone else.

A much better approach would be to have the "useEntity(counter)" return an object with "count", "increment" and "decrement" as its properties. This would make it much clearer, and if you want to have simple looking state variable and methods names you can just use ES6 destructuring syntax and you'd have it like this:

const { count, increment, decrement } = useEntity(counter);

Arnel Enero • Mar 16 '21 • Edited

Thanks for your reply. I do have a prior (well, it's still actively maintained) library called react-entities which does package the actions inside the entities.

Based on many user feedback, I decided that for this new library I would try decoupling the actions from the entity for reasons such as:

it makes it easier to implement orchestrator actions that can update multiple entities in one go (as discussed in the documentation)
it makes the "use" hook syntax simpler (returns a single value, not a tuple or destructuring)... more like useContext than useState.
the actions are pretty much static, so we are avoiding needlessly having to include them in the deps array of useCallback when invoking actions there.
many popular state managers like React Redux also separate actions/dispatch from the state hook
ultimately, I was aiming for "simplest" and based on feedback from users of react-entities standalone actions would be simpler (and more flexible).

Ski • Mar 19 '21

the actions are pretty much static, so we are avoiding needlessly having to include them in the deps array of useCallback when invoking actions there.

What you did in your example with "static" actions is global state singleton. It's a very bad example to teach. Many books talked about this. I suggest to revisit SOLID principles and try to apply them. All OOP concepts are very much applicable everywhere where there is state. And in UI there is a lot of state that needs to be managed.

Passing down dependencies is nothing wrong. It's the right way. When it's too much and interduces dependencies that we don't want to have - it can be avoided in React with useContext().

Arnel Enero • Mar 19 '21 • Edited

Just to be clear, this article is not intended to "teach" or even recommend certain "principles". It is merely to showcase—in the most succinct way possible—a library that some folks may choose to explore. And being designed exclusively to work with Hooks, it is obviously for those that prefer functional programming. There is never the intention to claim that it is the "best" approach, nor to compare with libraries, as the article has made clear.

As for the library itself, just like the over-simplified examples (not recommended patterns) used to demonstrate... it is not meant to challenge anybody's approach to development. It is unopinionated, and merely provides flexible building blocks that individuals can use while applying whatever programming principles they choose to adhere to.

Thomas Burleson • Mar 18 '21

The Zustand API [from the React Spring guys] is amazing and clean:

1) Use create(<callback to build>) to build a store, initialize state, and get a hook associated with that store
2) Use the hook (eg useStore(<query selector>)) to query/select data from the store.

Whenever that data slice changes, the hook re-emits and the component can re-render with up-to-date state.

@see github.com/pmndrs/zustand

Pablo Rocha • Mar 15 '21 • Edited

I like easy-peasy. Truly is the easiest react state management I've encountered. Uses redux under the hood so existing dev-tools work great.

github.com/ctrlplusb/easy-peasy

robvirtuoso • Mar 29 '21

Comments Section Summary:

Article: Introducing XXXXX. Can you suggest how to make it even easier?
Guy A: I like YYYY. Easiest I've encountered.
Guy B: Try ZZZZ it is even easier.
Guy C: The WWWW is amazing.
Guy D: Have you tried VVVVV?
Guy E: I also created a library UUUUU check it out...

You're a funny bunch!

Ivan Jeremic • Mar 15 '21

Try Recoil it is even easier

Alexander B.K. • Mar 18 '21

What about reactn : github.com/CharlesStover/reactn ?
There is an article which was written by the author in this site, from which I was interested in using it : dev.to/charlesstover/manage-global...
Well, I have been using it for managing global state in my last project. It worked as expected. For local state, I simply used React traditional way, i.e setState.

Jarod Smith • Mar 15 '21

Awesome academic exploration for yourself, but I think Kent is correct in this blog post, Application State Management with React. All you need is react.

Ski • Mar 19 '21 • Edited

State management is just writing code. Knowing multiple patterns their pros and cons and applying them to simplify application's complexity is the important part here. No library can ever solve this problem because it's education problem. The reason why redux achieved a lot is not because it actually solves anything. It's a tiny library that doesn't do much. It became wide spread not because it solves anything but because their documentation is quite an amazing guide on how to structure application that is easy for many to absorb and apply.

Arnel Enero • Mar 15 '21 • Edited

Thanks for your comment. After reading through that article, one would realize that as soon as the number of shared-state objects increases, assuming you're not using one monolithic global state, you'd go down the path of dealing with boilerplate. 😀

L. Rommy Arbantas • Mar 14 '21

Have you tried Valtio?
github.com/pmndrs/valtio

Andrey • Jun 1 '21 • Edited

Yes, it can get simpler, and it also needs to be more scalable and more powerful. Have a look at the Hookstate. It is as simple as React.useState API. It is hard to get any simpler than this, but at the same time Hookstate supports most (if not all) of state management needs, has got very impressive performance (Recoil, try to beat this: hookstate.js.org/docs/performance-...) and can be extended with custom plugins when needed. (Disclaimer, I am an author of the project)

robvirtuoso • Jun 1 '21 • Edited

So I see this kind of post again from the proud author of HookState, making comparisons as if it is a competition of who makes the best library.

Have you even tried these libraries being discussed in posts that you are hijacking? In this particular case you just enumerated what the library already does, as if they are missing in the library... so I guess you didn't bother to look.

I did stumble upon HookState earlier this year, and found that it overrides useState (by using the same name), and then changes its construct altogether, uses inconsistent parameter semantics for global vs. local usage, and on top of that, introduces a different output type for async state while using the same useState construct (talk about unpredictability!). Why would you do that??? After that, I looked elsewhere sorry.

(See, even if I am personally biased towards a different library, I didn't even feel the need to compare. I just objectively say why I didn't pick up HookState.)

Dude, one piece of unsolicited advice, stop promoting your own library in discussions that talk about another library. It is quite distasteful, and just brings a bad impression on your library to be honest.

Andrey • Jun 1 '21 • Edited

"hijacking?"
No, I expressed my opinion on the asked question if it can be any simpler.

"so I guess you didn't bother to look."
I looked at this.

"Why would you do that (use the same function name)???"
Because whatever the argument is, it gives you back the State object, which has got the same functionality regardless if a state variable comes from local variable, global variable, if it is a Promise or not.

" it overrides useState"
It does not override it. It just have got the same name because it does the same (for the case of the local state). If it is no-no, there is an alternative name 'useHookstate' or you can name alias on import or you can use module prefixes.

"different output type for async state"
No, you are not right with this statement. It is still an object of the same type with the same API and functionality.

"After that, I looked elsewhere sorry."
Good on you. I am quite glad you moved.

"I just objectively say why I didn't pick up HookState."
I got you objection comments on board. Thanks
Here is another view on Hookstate by someone else, who actually see it valuable: areknawo.com/top-5-react-state-man...

"stop promoting your own library in discussions that talk about another library"
Thanks for the advise. I hope you will take the effort to put down similar promotions everywhere around the internet? or maybe start with this article...
People pointing out to so many other alternatives all over the place. Many people said me "Thank you for the awesome library" after going to it from a "promotion" comment like this. So, I guess if there were no "promotional" comments people would not discover it and some of them would not get the tool which solves a real problem for them and makes them happy. I guess if I had a twitter account with millions of subscribers like some other "more well known" libraries use, I would not need to comment anywhere or even pay attention to comments like yours. At the same time I am a developer and prefer to write code, instead of developing marketing presence and twitter accounts. The tool I published solved a problem for me (no other state management library, I am aware of, solves the problem of performance of frequent deeply nested large state updates). I published it with the hope it makes life easier for somebody else too. And it did. I appreciate many will not bother even to look at it, because it does not come from Facebook or alike. But a few will and do use it, and it is enough.

robvirtuoso • Jun 1 '21 • Edited

I thought it prudent to repost here what I wrote in response to another conversation with you elsewhere... so that I may be completely fair to you. I do appreciate the effort you put into your library and for maintaining a good demeanor despite criticism.

---- Repost starting from here ---

I'm not trying to antagonize you. I just hate the idea that independent open source contributors like you will get a bad reputation due to their posts like this. I find publishing open source libs a noble thing to do, especially for people who don't earn a dime from it. You seem like you belong to this category, so I appreciate your efforts. I actually help promote work of libs that I personally use, as a way of giving back to the author/maintainer. If your posts triggered a bad reaction from me, it may happen with others too. So again I wouldn't wish you that misfortune.

You may not be asking for advice from me, but if it was me I would not want people thinking that I'm doing this to compete with the big guys (Redux, Recoil, etc.) which are backed by a big corporation and fanboys... And nor would I ever say that my lib is superior to another , popular or new one.... open source is not a popularity contest after all. As long as a number of people actually use your library, i.e. it is helping some folks out there, it means you already are doing a good job.

Shikhar • Mar 15 '21

I created something similar too very recently. I called it simate. A very (sim)ple st(ate) management tool. Have a look at it if you want :)
github.com/ceoshikhar/simate

Alexander B.K. • Mar 18 '21

In my last project, for local state, I simply used React traditional way, But for global state, due to time constraint (Mastering Redux would take longer time) I used reactn : github.com/CharlesStover/reactn
It was easy to use and worked well.
However, now I am going back to consider Redux again, because, in addition to the things mentioned in the documentation, for motivation to use it, I think I like the idea of storing states centrally (via store). Other reason for using Redux is because it is likely I will be working in a team that uses Redux. In my last project, I worked as a lone full-stack developer, so I could pick anything suitable.
Still, it will take time for me to learn and really use it in a real project. So, I also consider using Context and other built-in React API (useReducer) for achieving the same purpose, i.e dealing with global state.

Paul / Appurist • Mar 23 '21

As a fun project I tried to make the simplest reactive state, came up with this:
codepen.io/appurist/pen/QWdWzag?ed...

It too might be useful for others trying to avoid more complex framework state management.

I think it's quite a bit simpler, supports any types including subfields deeply nested within objects.

There's a more advanced example here:
github.com/appurist/reactivator/wi...
but if you look at the output, you'll see how capable it is (yet so simple to use).

Paul / Appurist • Mar 23 '21

Simpler example with a reactive state object here:
github.com/appurist/reactivator/wi...

Zaydek MG • Mar 16 '21 • Edited

Yeah. I’ve been thinking about this pattern myself. If you want to compare notes, here’s my minimalistic store implementation here: github.com/zaydek/retro/blob/go-re....

I think useState is a nice primitive but telling devs to ‘lift state to the parent component’ is actually somewhat of an anti-pattern. I researched Svelte quite a bit and Vue both seem to implement stores, which seem to be largely the same kind of API you are showing off here, if I’m not mistaken.

Thanks for sharing!

Baron Willeford • Mar 15 '21

github.com/baron816/use-structure

It’s just like using JS’s built in APIs. array.push does what you expect. Can use Sets, Maps, plain objects, classes, or some nested combination of the above, and everything works like you want it to. Nothing really to learn at all.

George K. • Apr 16 '21

Hi Arnel,
I was wondering if you would be interested in joining an online meetup to introduce SimpleR State (which I personally find awesomely simple :) ) to the audience of JS community of Barcelona.
Thanks!

Marcus Orciuch • Mar 15 '21

Pullstate is a great library I've been using instead of Redux

Ski • Mar 18 '21 • Edited

What happens if you need multiple instances of entity?

Arnel Enero • Mar 18 '21 • Edited

You can treat an entity just like a variable. Just declare as many entities as you want. Don't think of an entity as a class that you need to "instantiate".

For example:

export const counterA = entity(0)
export const counterB = entity(0)
export const counterC = entity(0)
// and so on...

And if you want to avoid declaring many actions that all look the same, you can do something like this:

const newCounter = () => {
  const counter = entity(0)
  const increment = by => { counter.set(value => value + by) }
  const reset = () => counter.set(0)

  return { counter, increment, reset }
}

const counterA = newCounter()
const counterB = newCounter()
const counterC = newCounter()

This library is flexible. You can do it however you prefer.

Ski • Mar 19 '21 • Edited

Don't think of an entity as a class that you need to "instantiate".

It's a very useful thought though - as every variable needs to instantiated with initial state. If it's class or not doesn't matter at all.

What I see here in your examples is completely no different of just using useState(). Thus I completely miss the point that you're trying to achieve.

const useCounterStore = () => {
  const [counter, setCounter]= useState()
  return { 
      counter,
      increment(by) {
         setCounter(counter+by)
      },
      reset() {
         setCounter(0)
      }
  }
}

function SomeComponent() {
   const counterA = useCounterStore()
   const counterB = useCounterStore()
   const counterC = useCounterStore()
}