Statera is a tiny React state library on npm (~169 bytes gzipped). Site: statera.sangeet.xyz.

It exists less as a feature race against Zustand or Redux, and more because of how people around me actually wrote apps.

What developers I knew actually used

Most of them did not live deep in advanced store features: middleware trees, fancy selectors, the whole catalog of extras bigger libraries advertise.

They used the mental model from useState: you get a value and a setter. They wanted that pattern available across components without dragging a heavy toolkit for edges they never touched.

So the job I cared about was: simple shared state, small size, familiar shape. Not “every pattern a state manager can grow into.”

What Statera is (and is not)

It is intentionally missing the laundry list of extras. That is fine. It aims at the feature majority of people were already paying for in larger packages: hold state, update it, re-render the right places, stay tiny.

If your team only ever uses a slice of Zustand like a shared useState, you might not need the rest of the surface area.

React 19 timing

I built this while React 19 was landing. I wanted something that felt close to native hooks. Keep the mental model in that world instead of inventing a parallel cosmology.

Keeping it small made “stay native-feeling” easier. Features you do not ship cannot fight the platform.

The boring challenge

First logic was not the hard part. Deleting bytes was. I once spent hours on a helper to save ~12 bytes. The build printing 169B felt absurdly good.

What I might add carefully

localStorage without blowing the budget. Maybe transitions. Easy to double the size by accident.

Why leave it public

A real package that matches how a lot of product engineers already think. Constraint exercise with a URL, not a slide about “DX.”