Atoms: The Unit of State in Jotai

In Jotai, state is broken into atoms: small, independent pieces of reactive state. Each atom holds a single value and is created outside of components with atom(initialValue).

This mirrors the mental model of splitting state into the smallest meaningful units, rather than one large store object.

When an atom's value changes, only the components that subscribed to that specific atom re-render. Components that read other atoms are unaffected.

This fine-grained reactivity is Jotai's core advantage over React Context, which re-renders all consumers on any change.

Define atoms at the module level: const countAtom = atom(0). This ensures the atom identity is stable across renders and the atom is not re-created on each component mount.

Atoms are lightweight references; they do not hold their own value. The value lives in the Jotai store.

By default, Jotai uses an implicit global store. You do not need to wrap your app in a Provider to start using atoms, which makes adoption simple in existing projects.

Atoms are globally accessible from any component in the tree without any prop drilling or context threading.

When you need multiple independent instances of the same component tree (e.g., two separate forms, each with their own form state atoms), wrap each in a Jotai Provider. Each Provider creates an isolated store.

This is useful for micro-frontend architectures or complex page layouts with independent state islands.

The global store persists atoms for the lifetime of the application. A scoped Provider store resets when the Provider unmounts, which is perfect for modal dialogs or page-level state that should not persist globally.

You can even pass a custom store instance to Provider for server-side rendering isolation.

Zustand uses a single store object with selectors to prevent unnecessary re-renders. Jotai divides state into atoms, and each component subscribes only to the atoms it reads.

Jotai is more natural for fine-grained UI state (individual input values, toggle flags). Zustand fits well for larger, interconnected application state.

React Context re-renders every consumer component whenever the context value changes, even if the consuming component only cares about one field in the context object.

Jotai solves this: a component using useAtom(nameAtom) only re-renders when nameAtom changes, not when any other atom changes.

Jotai uses Object.is comparison by default to determine if an atom's value has changed. If you set an atom to the same value it already holds, no re-render is triggered.

For complex objects, use the selectAtom utility to derive a stable primitive from a large atom, preventing re-renders when unrelated fields change.

useState is local to a single component. Atoms are shared across the entire component tree without explicit passing. When two sibling components read the same atom, they automatically stay in sync.

This eliminates the need to lift state up for cross-component sharing while keeping re-renders minimal.

Typical atoms: const themeAtom = atom('light'), const cartItemsAtom = atom([]), const selectedUserIdAtom = atom(null). These are defined once and imported anywhere in the application.

Each atom is independent: updating cartItemsAtom does not trigger re-renders in components that only read themeAtom.

How does Jotai differ from React Context in terms of re-rendering?

Atoms are the fundamental unit of state in Jotai, created with atom(initialValue) outside components and shared across the tree without Provider by default. When an atom changes, only its subscribers re-render.

This fine-grained reactivity is Jotai's key advantage over React Context, and its per-atom subscription model differs from Zustand's single-store approach.