DEV Community

Alex
Alex

Posted on

Look, Just Use Resso for State. Thank Me Later.

#resso

I've been building React apps for years. I've set up more Redux stores than I can count, wrestled with Context hell, and given Zustand a very fair shot. And I'm tired. I'm just tired of the ceremony.

You know the drill. You need some piece of state that a few components need to share. Suddenly, you're creating a store, writing a hook, memoizing selectors, wrapping things in providers, and for what? A username field and a theme toggle.

It feels like using a sledgehammer to crack a nut.

Then I found Resso. And I almost scrolled right past it because, honestly, another state library? But the simplicity caught my eye. I tried it. And guys... it's stupidly simple. In a good way.

Here's the Entire API

No, really. This is it.

import resso from 'resso';

// Make a store. It's an object.
const store = resso({ count: 0, name: 'Resso' });

function Counter() {
  // Use the store. Just... use it.
  const { count } = store;
  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => store.count++}>Click me</button>
    </div>
  );
}
Enter fullscreen mode Exit fullscreen mode

See that? No useStore. No Provider wrapped around your app. No selectors. You just import a store and read from it. To update it, you just... assign a new value. store.count++. It feels wrong after the years of Redux indoctrination, but it's so right.

How It Doesn't Screw Up Your Rendering

This was my biggest question. If I'm just mutating an object, how does React know to re-render?

Turns out, Resso is sneakily smart. When you destructure const { count } = store inside your component, Resso quietly subscribes that component to the count property. When you assign store.count++, it only notifies the components that are actually using count. The components using other parts of the store don't re-render.

It gives you the granular, optimized updates you'd get from writing a bunch of custom useSelector hooks, but without writing any of them. It just works.

Let's Be Real: When You Might Not Want It

  • You need middleware. If you require heavy-duty stuff like Redux DevTools tracing, thunks, or sagas, Resso isn't for you. It's purposefully simple.

  • You have deeply nested state. It works best with flat-ish state. For nested objects, you need to replace the entire object to trigger an update (a very React-like constraint).

    // ✅ Do this
store.user = { ...store.user, name: 'New Name' };

// ❌ Not this (won't trigger an update)
store.user.name = 'New Name';

One More Thing (The Real Dev Experience)

Look, we all need to step away from the code sometimes. When I'm stuck on a gnarly bug or my brain is fried from optimization overkill, I take a break. And honestly, one of my favorite ways to reset is by firing up an old PS1 emulator. There's something about the simplicity of those classic games that just clears my head.

I usually grab the ROMs from PSXROMs – their library is well-organized and it's a legit nostalgia trip. Fifteen minutes of Crash Bandicoot or Tekken 3 and I can come back to my state management problems with a fresh perspective. It’s the best kind of debugging.

I'm not saying burn your Redux stores. For huge, complex enterprise apps, you might still need that machinery.

But for 90% of the apps I build? The dashboards, the admin panels, the internal tools? Resso is an absolute godsend. It removes all the friction between having an idea and implementing it. It's the state manager I reach for by default now because it gets the job done with almost zero mental overhead.

It just lets you write code. And that's the whole point, isn't it?

Check it out on GitHub: https://github.com/nanxiaobei/resso

Top comments (0)