DEV Community: Andrey Gubanov

Stop Duplicating API State: A Zustand Registry That Auto-Updates Every Component

Andrey Gubanov — Tue, 07 Apr 2026 11:00:00 +0000

If your React app deals with interconnected data — users, tasks, comments, anything with relationships — you've probably felt the pain of keeping multiple components in sync. Update a user's name in a dialog, and now the sidebar, the header, and every task card showing that user all need to reflect the change. Lift state up? Duplicate fetch calls? None of it scales.

Entity-driven state normalization solves this. You extract entities into a flat, centralized registry keyed by ID. Every component reads from the same source. Update it once, everything re-renders automatically. And when you delete something, a trick with JavaScript property descriptors makes it invisible to iteration without crashing components that still reference it.

This article walks through a practical implementation using Zustand.

The core idea

Raw API responses are passed through a parse method that recursively extracts entities, normalizes them into flat dictionaries keyed by ID, and merges them into a Zustand store. Components subscribe to specific entities and re-render only when their data changes.

The contract is simple: every entity has an id and an entityType field. The registry uses these two properties to know what the entity is and where to store it.

Defining entity types

enum EntityType {
  user = 'user',
  task = 'task',
}

interface BaseEntity {
  id: string;
  entityType: EntityType;
}

In a real project, EntityType can come from DB as a column with fixed value, a codegen tool, or any other source of truth — the important thing is that your API responses include these fields. You can also use branded IDs (type UserId = string & { readonly __brand: 'user' }) to prevent mixing up entity types at compile time.

The registry store

The store defines a Registry interface with entity maps and a parse method:

import { create } from 'zustand';

interface Registry {
  [EntityType.user]: Record<string, UserType>;
  [EntityType.task]: Record<string, TaskType>;
  parse: (data: unknown) => void;
}

Extracting entities with `getEntitiesFromData`

The core of the pattern is a recursive function that walks any data structure and pulls out entities based on entityType + id:

const MAX_DEPTH = 10;

function getEntitiesFromData(data: unknown, entities = {}, depth = 0) {
  if (depth > MAX_DEPTH) return entities;

  if (Array.isArray(data)) {
    data.forEach((item) => getEntitiesFromData(item, entities, depth + 1));
  } else if (typeof data === 'object' && data !== null) {
    Object.values(data).forEach((value) =>
      getEntitiesFromData(value, entities, depth + 1)
    );
    if ('entityType' in data && 'id' in data) {
      const { entityType, id } = data;
      entities[entityType] ??= {};
      entities[entityType][id] = data;
    }
  }
  return entities;
}

Given a nested API response like this:

{
  "tasks": [
    {
      "id": "task-1",
      "title": "Task 1",
      "entityType": "task",
      "user": {
        "id": "user-1",
        "fullName": "John Doe",
        "entityType": "user"
      }
    }
  ]
}

The function produces a normalized shape in a single pass:

{
  task: { "task-1": { id: "task-1", title: "Task 1", entityType: "task", ... } },
  user: { "user-1": { id: "user-1", fullName: "John Doe", entityType: "user" } }
}

Nested entities are extracted alongside their parents — one call normalizes the entire response, no matter how deeply nested.

The `parse` method

The parse method calls getEntitiesFromData, then merges the results into the store. For each incoming entity it:

Checks if the entity already exists in state
Deep-compares old vs new with fast-deep-equal — if nothing changed, it skips the update entirely (no re-render)
Stores updated entities as non-writable property descriptors, and marks deleted entities as non-enumerable (more on this below)

The result: only components whose specific entity actually changed will re-render. You can see the full implementation on GitHub.

Soft deletions: the `enumerable: false` trick

This is my favorite part of the pattern.

When you delete an entity, you can't just remove it from the store — components still referencing that ID would crash. You could add a deleted flag and filter everywhere, but that leaks deletion logic into every consumer. Instead, the registry uses a JavaScript feature most people never think about: property enumerability.

When a property is defined with enumerable: false, it becomes invisible to Object.values, Object.keys, and { ...spread } — but it can still be accessed directly by key:

const obj = Object.defineProperties({}, {
  'task-1': { value: { id: 'task-1', title: 'Task 1' }, enumerable: true, configurable: true },
  'task-2': { value: { id: 'task-2', title: 'Task 2' }, enumerable: false, configurable: true },
});

Object.keys(obj);  // ['task-1'] — task-2 is invisible to iteration
obj['task-2'];     // { id: 'task-2', title: 'Task 2' } — still accessible by ID

Components iterating over entities won't see deleted ones. Components holding a reference to a specific ID won't crash. Zero awareness required from consuming code — deleted entities just disappear from enumeration.

To trigger a soft deletion, the server sends:

{ "id": "task-1", "entityType": "task", "__isDeleted": true }

Inside parse, one line handles it: enumerable: !('__isDeleted' in entity). That's it.

Using the registry in components

Reading a single entity by ID:

const UserProfile = ({ userId }: { userId: string }) => {
  const user = useRegistry(useShallow((state) => state.user[userId]));
  return <div>{user.fullName}</div>;
};

Listing all entities of a type:

const UserList = () => {
  const users = useRegistry(useShallow((state) => Object.values(state.user)));
  return <ul>{users.map((u) => <li key={u.id}>{u.fullName}</li>)}</ul>;
};

Object.values only iterates enumerable properties, so soft-deleted entities are automatically excluded — no extra filtering needed.

When a component receives a list of IDs from a parent, the same principle applies — but you need to account for deletions explicitly. Spreading the entity map creates a snapshot containing only enumerable (non-deleted) entries, so id in that snapshot acts as a deletion guard:

const UserList = ({ userIds }: { userIds: User['id'][] }) => {
  const users = useRegistry(
    useShallow(({ user: { ...userReg } }) => userIds.filter((id) => id in userReg).map((id) => userReg[id]))
  );
  return <ul>{users.map((u) => <li key={u.id}>{u.fullName}</li>)}</ul>;
};

{ ...userReg } copies only enumerable properties, so a deleted ID won't appear in the spread and gets filtered out. The deleted entity remains in the original store — it just can't be seen.

useShallow from zustand/shallow ensures components only re-render when the selected data actually changes, not on every store update.

Wiring it up to your data fetching

The pattern shines when every API response is automatically parsed. Call useRegistry.getState().parse(data) in whatever HTTP layer you use:

Plain fetch wrapper:

async function apiFetch<T>(url: string, options?: RequestInit): Promise<T> {
  const res = await fetch(url, options);
  const data = await res.json();
  useRegistry.getState().parse(data);
  return data;
}

Once this is in place, you never manually update the store. Make an API call, the registry extracts and normalizes all entities from the response, and every subscribing component updates automatically. This also works with streaming responses — if your API returns data incrementally (e.g. via JSON Lines), call parse on each chunk as it arrives.

Prior art

The idea comes from the Redux ecosystem. normalizr (by Paul Armstrong) introduced schema-based normalization, and Redux Toolkit's createEntityAdapter provided built-in CRUD operations for normalized state. This approach applies the same principle — flat dictionaries keyed by ID — but relies on convention (id + entityType) instead of upfront schema definitions.

The pattern isn't tied to Zustand either. Any state library with centralized stores and selective subscriptions works: Jotai, Valtio, or even Redux itself.

This is part of a larger architecture

This article is one piece of Realtime UI — a streaming-first architecture for Next.js built with Vovk.ts, covering real-time polling via Redis and JSON Lines, AI chat and voice integration, and MCP server support. It also goes deeper on SSR: Vovk.ts controllers expose a .fn() method that calls the handler directly on the server, so a Next.js server component can pre-populate the registry without an HTTP round-trip:

export default async function Home() {
  const [users, tasks] = await Promise.all([
    UserController.getUsers.fn(),
    TaskController.getTasks.fn(),
  ]);

  return (
    <RegistryProvider initialData={{ users, tasks }}>
      <UserList />
      <UserKanban />
    </RegistryProvider>
  );
}

No loading spinners, no empty-state flicker — the HTML arrives with data already rendered.

Read the full Realtime UI documentation | Browse the reference app source

Introducing Vovk.ts — A Back-End Framework Native to Next.js

Andrey Gubanov — Tue, 24 Mar 2026 13:00:00 +0000

After nearly three years of development, I'm releasing Vovk.ts — a back-end meta-framework built natively on top of Next.js App Router. It turns Route Handlers into a structured API layer with controllers, services, and procedures, and automatically generates type-safe RPC clients, OpenAPI specs, and AI tool definitions from your code.

If you've ever wanted the structured back-end experience of NestJS but without leaving the Next.js deployment model, this is what I've been building.

The idea in 30 seconds

Define a controller with validation in-place:

@prefix("users")
export default class UserController {
  @get('{id}')
  static getUser = procedure({
    params: z.object({ id: z.string().uuid() }),
    output: z.object({ id: z.string(), name: z.string() }),
  }).handle(async (req, { id }) => {
    return UserService.getUser(id);
  });
}

The CLI generates a type-safe client that mirrors the controller:

import { UserRPC } from 'vovk-client';

const user = await UserRPC.getUser({ params: { id: '123' } });

The same procedure runs locally for SSR — no HTTP round-trip:

await UserController.getUser.fn({ params: { id: '123' } });

And it's derivable as an AI tool in one call:

const { tools } = deriveTools({ modules: { UserRPC, TaskController } });
// [{ name, description, parameters, execute }, ...]

That's one endpoint definition generating a typed client, an OpenAPI spec, a local execution path, and an LLM-callable tool.

What it gives you

In-place validation with Zod, Valibot, or ArkType — no separate contracts or DTOs
Auto-generated TypeScript clients with jump-to-definition and JSDoc hover
OpenAPI 3.1 generation with Scalar-compatible docs
Per-segment serverless compilation — each route.ts is its own function with independent runtime config
Local procedure execution via .fn() for SSR, PPR, and background jobs
JSON Lines streaming with async function* generators
Third-party API mixins — import external OpenAPI specs and get the same typed client interface
AI tool derivation and MCP server support out of the box
Multi-language client generation (experimental) for Python and Rust
Multitenancy with built-in subdomain routing

What makes it different

If you've used tRPC, ts-rest, NestJS, oRPC, Hono, or ElysiaJS, many of the ideas here will feel familiar. Each of those tools does something genuinely well, and the patterns they've established informed many of the design decisions in Vovk.ts.

Where Vovk.ts carves its own path is in combining these ideas natively within Next.js App Router: the Controller–Service architecture from NestJS, the type-safe clients from tRPC, the REST compliance and OpenAPI generation from ts-rest. On top of that, it adds things I couldn't find elsewhere: local procedure execution via .fn() and built-in AI tool derivation for LLM agents and MCP servers.

It's not the right tool for every situation — if you're not on Next.js, or if you prefer a contract-first workflow, other options will serve you better. But if you're building a structured API layer on top of the App Router and want all of the above from a single source of truth, I think you'll enjoy it.

Get started

Run init command in an existing Next.js project to get started.

npx vovk-cli@latest init

📖 Documentation · 🐙 GitHub

I'd love to hear how your experience compares — what tools are you using for your Next.js API layer, and what's working (or not) for you?

Embracing the use-change library: a lightweight state management solution for React

Andrey Gubanov — Thu, 16 Mar 2023 21:09:40 +0000

Introduction

State management is an essential aspect of building scalable and maintainable React applications. While various state management libraries are available, such as Redux and MobX, some developers seek a more lightweight and straightforward solution for their projects. The use-change library offers a simple alternative for those who prefer a minimalistic approach.

What is the `use-change` Library?

The use-change library is an npm package that simplifies state management in React applications. It aims to reduce boilerplate code while providing an easy-to-use API for managing state. By leveraging React hooks, use-change offers a functional and reactive approach to state management. This library is perfect for developers who value clean syntax and minimal setup.

Key Features

Ease of use: The use-change library offers a simple learning curve and implementation process. Its intuitive API allows developers to manage state efficiently, enabling them to focus on their application's core functionality.
Lightweight: With a small footprint, use-change adds minimal overhead to your application, making it an ideal choice for performance-oriented projects.
Built with hooks: The library utilizes React hooks, ensuring seamless integration with other hooks-based components and a functional approach to state management.
Minimal boilerplate: use-change reduces the need for boilerplate code compared to other state management solutions, leading to a cleaner and more maintainable codebase.

Getting Started with `use-change`

First, install the use-change package using npm:

npm install use-change

Next, create your store:

export const store = {
  counter: 0,
};

Now, you can access and modify the state in your React components using the useChange hook:

import React from 'react';
import { useChange } from 'use-change';
import { store } from './store';

function Counter() {
  const [counter, setCounter] = useChange(store, 'counter');

  const increment = () => {
    setCounter(counter + 1);
  };

  return (
    <div>
      <p>Counter: {counter}</p>
      <button onClick={increment}>Increment</button>
    </div>
  );
}

export default Counter;

In the example above, the useChange hook accepts two parameters: the store and the key. The counter state property is connected to the Counter component, and when the state updates, the component will automatically re-render to keep the UI in sync with the state.

Conclusion

The use-change library offers a lightweight and straightforward solution for state management in React applications. With its minimalistic approach and easy-to-understand API, it is a great choice for small to medium-sized projects. If you're looking for an alternative to more complex state management libraries, give use-change a try and enjoy the simplicity it brings to your application development process.