Why it exists Most state libraries pick your architecture before you know if the app needs one: actions, reducers, selectors, a provider tree, decided on day one. Kin Store leaves that decision to you. set and dispatch are equally first-class, not a beginner tier and an advanced one, so the mutation style a store uses is a choice your team makes, not one the library makes for you.

What it does differently get, set, subscribe. Nothing else. Add methods, reducers, and middleware, one .use() at a time. Compose stores into new ones. It tracks what you read, not a graph you maintain. A store starts as get, set, subscribe, nothing else. Methods, reducers, middleware, and derived stores are things you add when you reach for them, not things you start with. No proxies, no auto-tracked reactive graph, no immer unless you add it. State only changes where you called set or dispatch. Each plugin declares what it adds. Stack ten of them and the chain still reads top-to-bottom, nothing nested to unwind. derive tracks which stores you read automatically. No selector library, no dependency array to keep in sync by hand.

Is Kin Store a fit?

Use it when state should start minimal

State should start minimal, not architected upfront
You want typed reducers, middleware, or devtools, only where it matters
You want structure and traceability, without the ceremony

Skip it when the simple thing is enough

You need server-owned state: that's TanStack Query/SWR's job
You need non-React bindings today; Vue, Svelte, and Solid aren't published yet
Redux or Zustand already works fine for your team

How it compares

For full comparison, see the details →

See it for yourself Declare ```ts import { createStore } from "@kintools/store-core"; const count = createStore(0); const theme = createStore<"light" | "dark">("light"); type TodoState = { items: string[]; status: "idle" | "loading"; }; const todos = createStore({ items: [], status: "idle", }); ```

Read, write, subscribe ```ts count.set((n) => n + 1); theme.set("dark"); todos.set((s) => ({ ...s, items: [...s.items, "Buy milk"] })); console.log(count.get()); // 1 const unsubscribe = count.subscribe((get, prev) => { console.log(prev, "->", get()); }); count.set((n) => n + 1); // logs "1 -> 2" ```

Compose `derive` automatically tracks dependencies without requiring a complex reactive graph runtime, thanks to the explicit `get(store)` calls. ```ts import { derive } from "@kintools/store-core"; const itemCount = derive((get) => get(todos).items.length); console.log(itemCount.get()); // 1 ```

When the store earns it, add structure Each `use()` registers a plugin (namespaced or top-level). Plugins are plain objects declaring methods, reducers, middleware, lifecycle hooks. Nothing wraps or patches the store. ```ts import { withPlugins } from "@kintools/store-core"; import { devtools, persist } from "@kintools/store-plugins"; const store = withPlugins(todos) .use("persist", persist({ key: "todos" })) .use("devtools", devtools()) .use({ methods: (store) => ({ addTodo(text: string): void { store.set((s) => ({ ...s, items: [...s.items, text] })); }, async fetchTodos(): Promise { store.set((s) => ({ ...s, status: "loading" })); const items = await api.fetchTodos(); store.set({ items, status: "idle" }); }, }), }); await store.persist.hydrate(); // From the namespaced persist plugin. store.addTodo("Buy milk"); // From the top-level inline plugin. ```

Need traceability? Add reducers and replace set by dispatch for those changes ```ts {5-9,12,14} const store = withPlugins(todos) .use("persist", persist({ key: "todos" })) .use("devtools", devtools()) .use({ reducers: { addTodo: (s, text: string) => ({ ...s, items: [...s.items, text] }), fetchStart: (s) => ({ ...s, status: "loading" }), fetchDone: (_s, items: string[]) => ({ items, status: "idle" }), }, methods: (store) => ({ async fetchTodos(): Promise { store.dispatch.fetchStart(); const items = await api.fetchTodos(); store.dispatch.fetchDone(items); }, }), }); store.dispatch.addTodo("Buy milk"); // Full intellisense, logged in devtools. ```
set/dispatch are both first-class here: pick whichever fits this store or method, not a ladder from one to the other.
In React ```tsx {5,7,12,19} import { useSelector, useStore } from "@kintools/store-react"; function Counter(): JSX.Element { // Re-renders on every change. Works great for primitive stores. const value = useStore(count); return ; } function TodoList(): JSX.Element { // Re-renders only when items changes. const items = useSelector(store, (s) => s.items); return (

{item}

); } ```