7.7k GitHub stars and counting — jamiebuilds/unstated is a JavaScript project TopGit is tracking across repositories on the platform. State so simple, it goes without saying
Snapshot summary built from the project's own GitHub metadata — there's no written TopGit review yet. The page will update automatically when a full review is published.
WHY NO REVIEW YET
TopGit writes full reviews for the most-starred, most-requested repositories. This page is a snapshot until then — see the READ ME tab for the original README in full.
"Unstated is a breath of fresh air for state management. I rewrote my whole app to use it yesterday."
Sindre Sorhus
"When people say you don't need Redux most of the time, they actually mean you do need Unstated. It's like setState on fucking horse steroids"
Ken Wheeler (obviously)
Guide
If you're like me, you're sick of all the ceremony around state management in
React, you want something that fits in well with the React way of thinking,
but doesn't command some crazy architecture and methodology.
So first off: Component state is nice! It makes sense and people can pick it
up quickly:
As a new React developer you might not know exactly how everything works, but
you can get a general sense pretty quickly.
The only problem here is that we can't easily share this state with other
components in our tree. Which is intentional! React components are designed to
be very self-contained.
What would be great is if we could replicate the nice parts of React's
component state API while sharing it across multiple components.
But how do we share values between components in React? Through "context".
Note: The following is part of the new React.createContext API
described in this RFC.
Behind the scenes our Containers are also event emitters that our app can
subscribe to for updates. When you call setState it triggers components to
re-render, be careful not to mutate this.state directly or your components
won't re-render.
setState()
setState() in Container mimics React's setState() method as closely as
possible.
If we want to test the relationship between our container and the component
we can again construct our own instance and inject it into the tree.
test('counter', async () => {
let counter = new CounterContainer();
let tree = render(
<Provider inject={[counter]}>
<Counter />
</Provider>
);
await click(tree, '#increment');
assert(counter.state.count === 1);
await click(tree, '#decrement');
assert(counter.state.count === 0);
});
Dependency injection is useful in many ways. Like if we wanted to stub out a
method in our state container we can do that painlessly.
test('counter', async () => {
let counter = new CounterContainer();
let inc = stub(counter, 'increment');
let dec = stub(counter, 'decrement');
let tree = render(
<Provider inject={[counter]}>
<Counter />
</Provider>
);
await click(tree, '#increment');
assert(inc.calls.length === 1);
assert(dec.calls.length === 0);
});
We don't even have to do anything to clean up after ourselves because we just
throw everything out afterwards.
FAQ
What state should I put into Unstated?
The React community has focused a lot on trying to put all their state in one
place. You could keep doing that with Unstated, but I wouldn't recommend it.
I would recommend a multi-part solution.
First, use local component state as much as you possibly can. That counter
example from above never should have been refactored away from component
state, it was fine before Unstated.
Second, use libraries to abstract away the bits of state that you'll repeat
over and over.
Like if form state has you down, you might want to use a library like
Final Form.
If fetching data is getting to be too much, maybe try out Apollo.
Or even something uncool but familiar and reliable like Backbone models and collections.
What? Are you too cool to use an old framework?
Third, a lot of shared state between components is localized to a few
components in the tree.
For this, I recommend using React's built-in React.createContext() API
and being careful in designing the API for the base components you create.
Note: If you're on an old version of React and want to use the new
context API, I've got you
Finally, (and only after other things are exhausted), if you really need
some global state to be shared throughout your app, you can use Unstated.
I know all of this might sound somehow more complicated, but it's a
matter of using the right tool for the job and not forcing a single
paradigm on the entire universe.
Unstated isn't ambitious, use it as you need it, it's nice and small for
that reason. Don't think of it as a "Redux killer". Don't go trying to
build complex tools on top of it. Don't reinvent the wheel. Just try it
out and see how you like it.
Passing your own instances directly to <Subscribe to>
If you want to use your own instance of a container directly to <Subscribe>
and you don't care about dependency injection, you can do so:
let counter = new CounterContainer();
function Counter() {
return (
<Subscribe to={[counter]}>
{counter => <div>...</div>}
</Subscribe>
);
}
You just need to keep a couple things in mind:
You are opting out of dependency injection, you won't be able to
<Provider inject> another instance in your tests.
Your instance will be local to whatever <Subscribe>'s you pass it to, you
will end up with multiple instances of your container if you don't pass the
same reference in everywhere.
Also remember that it is okay to use <Provider inject> in your application
code, you can pass your instance in there. It's probably better to do that in
most scenarios anyways (cause then you get dependency injection and all that
good stuff).
How can I pass in options to my container?
A good pattern for doing this might be to add a constructor to your container
which accepts props sorta like React components. Then create your own
instance of your container and pass it into <Provider inject>.
How does jamiebuilds/unstated compare to other Frontend projects?
jamiebuilds/unstated is tracked by TopGit in the Frontend category, with 7.7k GitHub stars and written in JavaScript. Browse the Frontend topic page on TopGit to compare it against similar projects by stars and activity.
Is jamiebuilds/unstated open source?
Yes — jamiebuilds/unstated ships under the MIT license, which makes its source code freely readable (and, depending on license terms, forkable and reusable). Source: github.com/jamiebuilds/unstated.
What else is in the Frontend space?
jamiebuilds/unstated is tracked by TopGit under the Frontend category, alongside 3 GitHub-tagged topics. Trending and Topics pages list peer repositories of comparable stars and language.
What is jamiebuilds/unstated?
jamiebuilds/unstated (jamiebuilds/unstated) is a JavaScript project on GitHub. From the project's own README: State so simple, it goes without saying
Where do I read more about jamiebuilds/unstated?
This TopGit page is a snapshot — the READ ME tab shows the project's own README content (links stripped, images preserved). The GitHub repository at github.com/jamiebuilds/unstated is the definitive source.
Why is jamiebuilds/unstated categorized under Frontend?
TopGit places jamiebuilds/unstated in the Frontend category based on its GitHub topics and description (tagged: "management", "react", "state"). Categories are assigned from real repository metadata, not editorial guesswork.
Read full README in the tab above.
Want a second opinion on unstated?
Ask an AI that can read this page — one click and you get its take on unstated.