DEV Community: Man Hoang

[Boost]

Man Hoang — Sun, 06 Sep 2026 15:35:47 +0000

Man Hoang

Sep 3

I Kept Rebuilding Form APIs. So I Finally Built Kin Form.

#showdev #opensource #react #typescript

7 min read

I Kept Rebuilding Form APIs. So I Finally Built Kin Form.

Man Hoang — Thu, 03 Sep 2026 14:58:43 +0000

I've spent a surprising amount of my career building admin portals.

There were four of them in total: two at Accumulus and two at Restful Mind. In both cases, the “two” came from rebuilding a portal with a new stack.

And admin portals, as anyone who has worked on one knows, are mostly forms.

Some were simple. Some were not. At Accumulus alone, we had around forty forms covering products, plans, coupons, subscriptions, and all the business rules that come with a mature SaaS product.

So I've had plenty of reasons to think about form state.

It started as part of a UI library

I never planned to build a standalone form library.

The form API evolved through several projects and a few different designs.

Project	Stack	Form model
Admin portal 1 (Accumulus)	Polymer + Dart	Flat, UI-coupled
Admin portal 2 (Accumulus)	Lit + TypeScript	Tree, UI-coupled
Admin portal 3 (Restful Mind)	React + TypeScript	React Hook Form
Admin portal 4 (Restful Mind)	Lit + TypeScript	Flat, UI-coupled
Kin Form (extracted package, Lit only)	Lit + TypeScript	Tree, UI-coupled
Kin Form (framework-agnostic)	TypeScript	Tree, UI-free

The first version was built at Accumulus for a Polymer/Dart admin portal. It had a fairly simple model: a form and a collection of fields similar to the web's native form and input elements.

When we rebuilt the UI with Lit and TypeScript, I redesigned the form API around a tree based on @angular/forms. A form control could either be a leaf control or a collection of child controls. This worked much better for the complex forms (with nested groups/arrays) we were building.

At Restful Mind, the first admin portal used React Hook Form and Chakra UI. React Hook Form was usable but it didn't quite feel right to me. I found myself thinking about forms differently: less as a collection of inputs connected to a form, and more as structured state with its own hierarchy and behavior.

For the second admin portal at Restful Mind, I simplified the API again to be flat with just FormController and FormField.

After finishing my work at Restful Mind, I decided to extract the form API from the UI library into a standalone package for Lit and published it to JSR and npm. For this initial Kin Form, I went back to the tree model as it better supports nested groups/arrays.

LitElement → FormField → FieldGroup → FormController

This was the first time the form API existed independently of the UI library.

But it was still tied to Lit.

Lit has a smaller ecosystem than React. If I wanted Kin Form to reach more
developers, I would need to make it work with React and other frameworks.

I remembered that TanStack already had a framework-agnostic form library, so I looked at TanStack Form for some ideas. It confirmed that separating form state from the UI framework was a direction worth exploring.

But I also wanted to keep the tree model I had arrived at through the Lit
versions, while making the nodes themselves independent of UI components.

That led to the current design of Kin Form:

BaseApi → FieldApi → FormApi

BaseApi provides the pub/sub mechanism. FieldApi adds state, configuration, field operations, parent relationships, and child registration. FormApi adds form-level operations such as reset and submit.

The important part is that every node in the form tree is a FieldApi.

FormApi isn't required to use the tree. You can work with a FieldApi tree and handle things like reset and submission yourself. FormApi simply adds those form-level operations when you want them.

The nodes are no longer UI components. They are framework-agnostic state objects that can be connected to React, Lit, or another UI framework.

That became the new Kin Form: a framework-agnostic, type-safe form state library for TypeScript, with bindings for React and Lit (and more to come).

The idea is simple: a form is a tree

Forms tend to grow in a predictable way.

You start with a name and an email address. Then you add an address. Then maybe a list of contacts. Then conditional fields. Then validation that depends on another field. Eventually you have tables where users can add, remove, and reorder rows.

At that point, the form is no longer just a collection of inputs. It's a piece of application state with a structure of its own.

The model I settled on is simple:

A form is a tree, and every node in that tree follows the same model. Each node has its own state, configuration, and subscribers.

Nested groups, arrays, and leaf fields all use the FieldApi model. There doesn't need to be a separate abstraction every time the value gets more complicated.

The form tree doesn't have to mirror the value shape exactly, either.

Given the same value type, you can choose how much structure you want in the form tree. A form can be completely flat, fully nested, or somewhere in between.

For example, a value like:

type Order = {
  email: string;
  items: {
    name: string;
    quantity: number;
  }[];
  shipping: {
    line1: string;
    line2: string;
  };
};

can be represented as

// Completely flat

Form
├── email
├── items.0.name
├── items.0.quantity
├── shipping.line1
└── shipping.line2


// Fully nested

Form
├── email
├── items
|   └── 0
|       ├── name
|       └── quantity
└── shipping
    ├── line1
    └── line2


// Somewhere in between

Form
├── email
├── items.0.name
├── items.0.quantity
└── shipping
    ├── line1
    └── line2

All three trees represent the same value. The difference is how the form state is organized.

This makes the tree a useful composition mechanism rather than a constraint imposed by the value structure. You can introduce a group when you need shared behavior, validation, subscriptions, or reusable components without having to change the underlying value shape.

Forms should read like composition

This is probably the part of Kin Form that best shows what I was trying to do.

Instead of passing a form context around and having each component figure out which part of the form it needs, a component gets the node it works with:

// React
<form onSubmit={form.handleSubmit}>
  <TextField api={form.field("email")} label="Email" />
  <AddressField api={form.field("shipping")} />
  <AddressField api={form.field("billing")} />
  <ItemsField api={form.field("items")} />
  <SubmitButton api={form}>Place order</SubmitButton>
</form>

// Lit
html`
  <form @submit=${form.handleSubmit}>
    <text-field .api=${form.field("email")} label="Email"></text-field>
    <address-field .api=${form.field("shipping")}></address-field>
    <address-field .api=${form.field("billing")}></address-field>
    <items-field .api=${form.field("items")}></items-field>
    <submit-button .api=${form}>Place order</submit-button>
  </form>
`;

Each component receives a resolved FieldApi, rather than a path or a form context. The component just focuses on its UI and behavior without dealing with how to obtain the FieldApi or where it lives in the form tree. This approach significantly simplifies component implementation and enables 100% type safety.

This means I can build a field component once and use it wherever its value type fits.

The core doesn't know about UI frameworks

The form state itself shouldn't need to know how it's being rendered.

Kin Form has a framework-agnostic core, with framework bindings on top of it. The bindings take care of subscriptions and connecting the form state to the framework's rendering model.

For example, a reusable TextField receives a FieldApi:

// React

export type TextFieldProps<TParentValue> = {
  api: FieldApi<string, TParentValue>;
  label: string;
}

export function TextField<TParentValue>({
  api,
  label,
}: TextFieldProps<TParentValue>) {
  const field = useWatch(api);

  return (
    <label>
      {label}
      <input
        value={field.value}
        onBlur={field.handleBlur}
        onChange={(e) => field.handleChange(e.target.value)}
      />
      {field.touched && field.invalid && (
        <span>{field.error ?? field.schemaError}</span>
      )}
    </label>
  );
}

// Lit

@customElement("text-field")
export class TextField extends LitElement {
  @property({ attribute: false })
  accessor api!: FieldApi<string, unknown>;

  @property()
  accessor label = "";

  #watch = new WatchController(this, () => this.api);

  override render() {
    const field = this.#watch.value;

    return html`
      <label>
        ${this.label}
        <input
          .value=${field.value}
          @blur=${field.handleBlur}
          @input=${(e: Event) =>
            field.handleChange((e.target as HTMLInputElement).value)}
        >
      </label>
    `;
  }
}

The implementations are framework-specific, as they should be. The form API they
consume is not.

That's the separation I wanted when I started the rewrite.

What I care about in the design

The main things I wanted to get right were type safety, nested groups, dynamic arrays, reusable field components, and keeping the API relatively small.

Some of the details follow naturally from the tree model.

For example, a path such as field("items.0.name") is checked against the
form's value type. Array operations such as push, insert, move, swap, and remove are part of the same field model rather than requiring a separate array API.

Validation can be scoped to a field, a subtree or the whole form, and fields can declare dependents when validation needs to react to changes elsewhere.

Subscriptions are also scoped to the nodes that need them, so a change doesn't have to cause the entire form to update.

These aren't separate features that I added one by one. They're mostly
consequences of having the same model at every level of the tree.

How it compares

The design was the main reason I built Kin Form, but performance and bundle size still matter for a library like this. Below is how Kin Form compares with React Hook Form, Formik, and TanStack Form.

Those numbers come from my own benchmarks, so I wouldn't treat them as absolute. The scenarios and implementation details matter. For full comparison, see here.

For me, the more interesting question is whether the design makes real forms easier to build and maintain.

When it makes sense, and when it doesn't

Kin Form isn't something I think every form needs.

If you're building a small login or contact form, component-local state may be all you need. And if your team already has a form library that works well, there may be no reason to switch.

Kin Form is well suited to forms with shared field components, nested objects, dynamic arrays, multiple steps, flexible validation, or state that needs to survive UI unmounts and remounts.

That's the kind of problem I built it for.

Still learning in public

This is the first version of Kin Form that I'm putting out as an independent, framework-agnostic library.

I expect the design to change as more people use it. There are forms and use cases I haven't encountered yet, and those are usually where the most useful feedback comes from.

Kin Form is now part of Kintools, where I'm bringing together small, focused tools built from ideas I've found useful in real applications.

You can explore Kin Form and its documentation at kintools.dev/form.

If you try it, I'd love to hear whether the tree model feels natural when
building real-world forms, and where it gets in your way.

That's the part I'm most interested in learning next.

[Boost]

Man Hoang — Sat, 04 Jul 2026 16:31:42 +0000

Man Hoang

Jul 1

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

#showdev #typescript #opensource #react

9 min read

[Boost]

Man Hoang — Fri, 03 Jul 2026 16:27:47 +0000

Man Hoang

Jul 1

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

#showdev #typescript #opensource #react

9 min read

[Boost]

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

Man Hoang

Jul 1

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

#showdev #typescript #opensource #react

9 min read

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]

I Kept Rebuilding Form APIs. So I Finally Built Kin Form.

I Kept Rebuilding Form APIs. So I Finally Built Kin Form.

It started as part of a UI library

The idea is simple: a form is a tree

Forms should read like composition

The core doesn't know about UI frameworks

What I care about in the design

How it compares

When it makes sense, and when it doesn't

Still learning in public

[Boost]

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

[Boost]

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

[Boost]

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

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

What Felt Off About Zustand

The Evolution

Three Primitives, Opt-in Complexity

createStore: the floor

withPlugins: opt-in structure

derive: lazy computed state

How It Compares

React in One Hook

Try It

`createStore`: the floor

`withPlugins`: opt-in structure

`derive`: lazy computed state