Zustand Felt Off. Redux Was a No. So I Built My Own.

Man Hoang — Wed, 01 Jul 2026 13:00:00 +0000

I was building MiniSlack, a hands-on project to learn system design and microservices, when I hit a wall in a form component.

It was just three fields, but once I added client-side validation, the setup no longer looked clean.

The app was going to have more forms, so reaching for a form library made sense. I wanted something more powerful than a thin wrapper over native form elements, which ruled out Radix Form. But the more powerful options, Formik, React Hook Form, and TanStack Form, all felt heavier than form management should need to be.

I had built a form library for Lit before, so I thought I might build one for React too, as a learning experience.

As soon as I started prototyping, I ran into state management.

TanStack Form solves this with TanStack Store, its own state library. I read through TanStack Store, but it turned out to be more complex (internally) than I expected. Redux was never really a choice for me because of its ceremony. I remembered Zustand, which I had briefly used on a team project. I pulled it up and read through it again.

Something felt off.

What Felt Off About Zustand

The more I read, the more specific the feeling became. Here is a simple Zustand store with a few features wired up:

const useStore = create(
  devtools(
    persist(
      immer((set) => ({
        todos: [],
        addTodo: (text: string) =>
          set((draft) => {
            draft.todos.push(text);
          }),
      })),
      { name: "todos-storage" },
    ),
    { name: "TodoStore" },
  ),
);

function TodoApp() {
  const todos = useStore((s) => s.todos);
  const addTodo = useStore((s) => s.addTodo);
  //...
}

Five things kept bothering me.

State and actions mixed together. todos is data. addTodo is logic. They live in the same object. From a typing perspective, there is no structural boundary between data and logic.

The API has a circular shape. You receive set inside the create
callback, before the store is finalized. That makes the authoring experience feel backwards: you define the thing while already depending on the thing being defined.

No type safety by default. Paste the code above into an IDE and TypeScript complains: parameter draft implicitly has an any type. Without an explicit annotation, nothing is inferred. For a library claiming to be TypeScript-first, type inference should be free.

Getting an action reference requires a subscription. Calling
useStore((s) => s.addTodo) registers a selector subscription just to return a function reference that never changes. It does not trigger re-renders, but the subscription still runs on state changes. This is unnecessarily inefficient for something that could just be imported and called.

The middleware model nests. The devtools(persist(immer(...))) onion reads left-to-right but executes right-to-left. Zustand calls these "middleware," but they behave more like decorators: each one wraps the store and can reshape its API. Order matters because wrappers such as devtools and immer can both affect the behavior and type of setState. Adding one more capability means adding one more level of nesting.

At this point I was deep in the rabbit hole — and the form library was no longer the point. I wanted to build a better Zustand.

The Evolution

I decided to recreate the core of Zustand to fully understand the problems and see what I would do differently.

I started with four goals:

separate state from actions
avoid the circular create((set) => ...) shape
make TypeScript inference work by default
get rid of that subscription for action reference

After some iterations, I got the following:

type Actions = Record<string, (...args: any[]) => void>;

export type Store<TState, TActions extends Actions = {}> = {
  getState(): TState;
  setState(next: TState | Updater<TState>): void;
  subscribe(cb: Listener<TState>): VoidFunction;
} & TActions;

export function createStore<TState, TActions extends Actions>(options: {
  initialState: TState;
  actions?: (store: Store<TState>) => TActions;
}): Store<TState, TActions>;

const todoStore = createStore({
  initialState: { todos: [] as string[] },
  actions: (store) => ({
    addTodo(text: string): void {
      store.setState((s) => ({ todos: [...s.todos, text] }));
    },
  }),
});

// Actions become methods and can be called directly.
todoStore.addTodo("Buy groceries");

todoStore.getState(); // { todos: ["Buy groceries"] }

State and actions were now separated. Everything was fully inferred. No circular reference since store passed to actions didn't have TActions. Actions became
methods that could be called directly; no subscription required. All four goals achieved! Then I started thinking about traceability.

One idea was to add a hint or metadata parameter to setState, so the call site could pass extra context about what changed and why. The hint could be any type, and users could constrain it via a type argument on createStore.

But that pushed the API in an awkward direction. TypeScript cannot partially infer type arguments, so users would end up specifying all type arguments manually just to get meaningful metadata. Free-form hints also do not give you much structure. If you want traceability that actually means something, you eventually arrive at the same ideas Redux is built around: named operations, a dispatch function, and a middleware pipeline that every mutation can flow through.

Which way to go? The Redux way or the Zustand way?

Then I realized both could be supported cleanly. Use setState when you want direct mutation. Use dispatch.* when you want named operations that travel through middleware. The user chooses the mutation style that fits the situation instead of committing the entire store to one model. Under the hood, dispatch.* is built on top of setState.

With reducers and middleware added, there were now two types of actions:
reducer-based actions (store.dispatch.addTodo(...)) and regular actions
(store.addTodo(...)). So, options.actions was renamed to methods to remove the overloading and better describe what it is.

The next problem was API surface. As I added support for reducers and
middleware, the options object passed to createStore kept growing and Store now had a middleware pipeline builtin. Developers who only want a simple store (no methods, no reducers) would have to pay for features they did not ask for.

This is when the plugin idea popped up.

I recalled how web frameworks already handled middleware ergonomically:

app.use(logger).use(compression).use(cors);

One flat chain. Additive. Top-to-bottom. It's for middleware, but can be used
for plugins too.

Wait. What is a plugin? What is middleware? Zustand's middleware is confusing,
so let's define these terms clearly

Middleware: pipeline interceptor
Reducer: pure function that transitions state
Plugin: extra capability

Now, what if the core store was just three methods, and everything else was a
plugin?

Reducers, middleware, methods, lifecycle hooks: none of it baked into the
minimal store, all of it available one .use() at a time. Complexity is opt-in
and you only pay for what you use.

After more iterations, the API looked like this:

// Creates a minimal store.
export function createStore<TState>(initialState: TState): Store<TState>;

// Upgrades an existing store or creates a new one with plugin support.
export function withPlugins<TState>(
  input: Store<TState> | TState,
): StoreWithPlugins<TState>;

After that, I looked at how Jotai and TanStack Store handle composition. I found
derive-zustand and built derive based on it: auto-tracked, lazy derived
state without a full reactive graph runtime. Then I added official plugins for
persistence, history, and Immer, followed by React bindings.

One last thing changed near the end. The API was using getState and
setState, familiar names for anyone coming from React or Zustand. But once the
library settled, those names felt too heavy for a store whose core contract was
only three methods. So getState became get. setState became set.

That is Kin Store.

Three Primitives, Opt-in Complexity

`createStore`: the floor

createStore is a dead-simple function that takes an initial state and returns
a store object with only three methods: get, set, and subscribe.

import { createStore } from "@kin-store/core/index.ts";

type TodoState = { todos: string[]; status: "idle" | "loading" };

const store = createStore({ todos: [], status: "idle" } as TodoState);

function addTodo(text: string): void {
  store.set((s) => ({ ...s, todos: [...s.todos, text] }));
}

store.subscribe((get) => console.log("current state:", get()));

Three methods. get() reads state. set() updates it with either a value or an
updater function. subscribe() registers a listener and returns an unsubscribe
function.

That is the whole contract. No proxy, no hidden merge, no magic.

`withPlugins`: opt-in structure

When you want colocated logic, reach for withPlugins and add methods.

import { withPlugins } from "@kin-store/core/index.ts";

const todoStore = withPlugins({ todos: [], status: "idle" } as TodoState).use({
  methods: (store) => ({
    addTodo(text: string): void {
      store.set((s) => ({ ...s, todos: [...s.todos, text] }));
    },
    async fetchTodos(): Promise<void> {
      store.set((s) => ({ ...s, status: "loading" }));
      const todos = await fetch("/api/todos").then((r) => r.json());
      store.set({ todos, status: "idle" });
    },
  }),
});

todoStore.addTodo("Buy groceries");
await todoStore.fetchTodos();

Need persistence or undo/redo? Add plugins. No rewrapping:

import { withPlugins } from "@kin-store/core/index.ts";
import { history, persist } from "@kin-store/plugins/index.ts";

const todoStore = withPlugins({ todos: [] as string[], status: "idle" })
  .use("persist", persist({ key: "todos" }))
  .use("history", history())
  .use({
    methods: (store) => ({
      addTodo(text: string): void {
        store.set((s) => ({ ...s, todos: [...s.todos, text] }));
      },
    }),
  });

await todoStore.persist.hydrate();
todoStore.history.undo();

The namespace is yours to control. "persist" and "history" are the
namespaces you choose. In Zustand, middleware decides where their added APIs
live; users have no control over this. In Kin Store, the string you pass to
.use() becomes the namespace. Each plugin is one .use() call, not another
wrapper around the store.

Next, if you want traceability, add reducers and replace set(...) with
dispatch.*(...):

const todoStore = withPlugins({ todos: [] as string[], status: "idle" })
  .use("persist", persist({ key: "todos" }))
  .use({
    reducers: {
      addTodo: (state, text: string) => ({
        ...state,
        todos: [...state.todos, text],
      }),
      fetchStart: (state) => ({ ...state, status: "loading" }),
      fetchFulfilled: (_state, todos: string[]) => ({ todos, status: "idle" }),
    },
    middleware: () => (ctx, next) => {
      console.log("->", ctx.reducer.name);
      return next();
    },
    methods: (store) => ({
      async fetchTodos(): Promise<void> {
        store.dispatch.fetchStart();
        const todos = await fetch("/api/todos").then((r) => r.json());
        store.dispatch.fetchFulfilled(todos);
      },
    }),
  });

todoStore.dispatch.addTodo("Buy groceries");
await todoStore.fetchTodos();

Again, everything is fully inferred. Hover over ctx.reducer.name and you'll
see "addTodo" | "fetchStart" | "fetchFulfilled". Hover over dispatch.addTodo
and you editor shows (text: string) => void.

`derive`: lazy computed state

derive creates a read-only store whose value is computed from other stores.

import { createStore, derive } from "@kin-store/core/index.ts";

const userStore = createStore({ name: "Alice" });
const cartStore = createStore({ items: [] as string[] });

const summary = derive((get) => ({
  greeting: `Hello, ${get(userStore).name}`,
  itemCount: get(cartStore).items.length,
}));

Call get(someStore) inside the compute function and the dependency is tracked
automatically. No selector arrays to maintain. No createSelector. No
useMemo.

If a store you read in one run is not accessed in the next run, that dependency
is dropped automatically. Conditional derived state stays accurate without
manual bookkeeping.

"Lazy" means the compute function does not run until something reads the derived
store. Stores nobody reads cost nothing to compute. Under the hood, it is just
two Maps and one Set: no reactive graph runtime, no propagation algorithm.

How It Compares

	Kin Store	Zustand	Redux / RTK	Jotai	MobX
Bundle size	244 B (minimal) 465 B (composition) 1.07 KB (plugin support)	~1.1 KB	~10 KB	~3.5 KB	~16 KB
Zero dependencies	✅	✅	❌	✅	✅
100% type-safe	✅	⚠️	⚠️	✅	✅
Low boilerplate	✅	⚠️	❌	⚠️	⚠️
Separate state & logic	✅	❌	✅	—	✅
Opt-in complexity	✅	✅	❌	⚠️	❌
No hidden magic	✅	✅	✅	✅	❌

✅ full · ⚠️ partial or conditional · — not applicable (different model)

The comparison page at kinstore.dev has full,
working implementations of the same todo store in each library. A few
highlights:

vs. Zustand — State and actions are structurally separate. TypeScript
inference works without an explicit create<State>() annotation. Plugins
compose with .use() (top-to-bottom) instead of nesting (inside-out). Methods
live on the store object and are called directly — no subscription needed.

vs. Redux / RTK — No createAsyncThunk, no extraReducers, no
configureStore, no manually exported RootState and AppDispatch types. Kin
Store supports the same ideas — reducers, a middleware pipeline — without the
ceremony. Async logic is a method or function that calls reducers; no separate
thunk concept.

vs. Jotai — Jotai is atom-based: every field is an atom, and app logic must
be wrapped in atoms. Write atoms are activated via useSetAtom inside React, or
getDefaultStore() outside — there is no plain function path. Kin Store uses
plain functions/methods and domain-shaped stores. Logic can run anywhere.

vs. MobX — No makeAutoObservable, no runInAction, no observer()
wrapper on every React component. MobX makes it easy to create stale UI if one
forgets to wrap mutations in runInAction after await, or forgets to wrap
components reading state in observer. Kin Store's mutations are explicit: call
set or dispatch.*, and that's it.

React in One Hook

import { useSelector } from "@kin-store/react/index.ts";

function TodoApp() {
  const todos = useSelector(todoStore, (s) => s.todos);
  return (
    <ul>
      {todos.map((t) => <li key={t}>{t}</li>)}

      {/* If using methods */}
      <button onClick={() => todoStore.addTodo("Buy groceries")}>Add</button>

      {/* If using reducers */}
      <button onClick={() => todoStore.dispatch.addTodo("Buy groceries")}>
        Add
      </button>
    </ul>
  );
}

useSelector is backed by useSyncExternalStore, the primitive React's team
recommends for external store subscriptions. No tearing. No stale closures. No
context required.

Call methods or dispatch actions directly on the store. No useDispatch hook.
No dispatch() wrapper. The store is a plain object created outside React, so
you can import it and use it.

A StoreProvider and useStoreContext exist if you need dependency injection
for testing or SSR, but they are opt-in.

Try It

# For React (@kin-store/core included)
deno add jsr:@kin-store/react
pnpm add jsr:@kin-store/react
yarn add jsr:@kin-store/react
npx jsr add @kin-store/react

# For vanilla projects
deno add jsr:@kin-store/core
pnpm add jsr:@kin-store/core
yarn add jsr:@kin-store/core
npx jsr add @kin-store/core

# Official plugins (persist, history, immer)
deno add jsr:@kin-store/plugins
pnpm add jsr:@kin-store/plugins
yarn add jsr:@kin-store/plugins
npx jsr add @kin-store/plugins

Full docs and the complete comparison: kinstore.dev

Looking back, it was a fascinating journey. From a form with three fields to a
brand new state library. Completely unexpected.

If existing state libraries have ever felt off to you, give Kin Store five
minutes.

DEV Community: Man Hoang

[Boost]