Forem: axtk

Harmonizing shared state with local state in React

axtk — Fri, 24 Oct 2025 21:49:44 +0000

The split between the mental models of local and shared state management in React apps has been around since time immemorial. Here's an example of how to do these conceptually similar things in a very similar way:

+ import { Store, useStore } from "@t8/react-store";
+
+ let counterStore = new Store(0);

  let Counter = () => {
-   let [counter, setCounter] = useState(0);
+   let [counter, setCounter] = useStore(counterStore);

    let handleClick = () => {
      setCounter(value => value + 1);
    };

    return <button onClick={handleClick}>+ {counter}</button>;
  };

  let ResetButton = () => {
-   let [, setCounter] = useState(0);
+   let [, setCounter] = useStore(counterStore, false);

    let handleClick = () => {
      setCounter(0);
    };

    return <button onClick={handleClick}>×</button>;
  };

  let App = () => <><Counter/>{" "}<ResetButton/></>;

This is a full-fledged shared state setup. Similar handling of local and shared state means a short migration path from one to another without tedious refactors.

More details on this package can be found in its concise overview.

Managing URL parameters as state in React

axtk — Wed, 17 Sep 2025 10:51:37 +0000

Since URL parameters can be regarded as a portion of an app's state, it's only reasonable to think of managing them in the React way of managing state: similarly to useState().

From this perspective, here's what handling the URL params state of, let's say, the root URL / would look like:

  export const App = () => {
-   let [{ coords }, setState] = useState({ coords: {} });
+   let [{ query }, setState] = useRouteState("/");

    let setPosition = () => {
      setState((state) => ({
        ...state,
-       coords: {
+       query: {
          x: Math.floor(100 * Math.random()),
          y: Math.floor(100 * Math.random()),
        },
      }));
    };

    return (
      <main>
-       <Shape x={coords.x} y={coords.y}/>
+       <Shape x={query.x} y={query.y}/>
        <p><button onClick={setPosition}>Move</button></p>
      </main>
    );
  };

The similarity of this code to the React's useState() setup makes it familiar right away and streamlines the migration from local state to the URL params state, so it looks like a way to go.

This perspective fits well with the minimalist approach to routing I outlined in a recent post. That's why the useRouteState() hook from the code above is part of this approach, so now we can turn this code into a live demo.

In this approach, the route state can also be handled with preciser typing by introducing a type-safe URL builder url() and a zod-powered URL schema (as described in another post), although it's completely optional:

import { useRouteState } from "@t8/react-router";
import { createURLSchema } from "url-shape";
import { z } from "zod";

const { url } = createURLSchema({
  "/shapes/:id": {
    params: z.object({
      id: z.coerce.number(),
    }),
    query: z.optional(
      z.object({
        x: z.coerce.number(),
        y: z.coerce.number(),
      })
    ),
  },
});

export const ShapeSection = () => {
  let [{ params, query }, setState] = useRouteState(url("/shapes/:id"));

  let setPosition = () => {
    setState((state) => ({
      ...state,
      query: {
        x: Math.floor(100 * Math.random()),
        y: Math.floor(100 * Math.random()),
      },
    }));
  };

  let resetPosition = () => {
    setState({ params });
  };

  return (
    <main>
      <h1>Shape {params.id}</h1>
      <Shape x={query.x} y={query.y} n={params.id + 2}/>
      <p>
        <button onClick={setPosition}>Move</button>{" "}
        <button onClick={resetPosition}>Reset</button>
      </p>
    </main>
  );
};

View live demo

Compared to the first example, we've essentially added a URL schema definition with createURLSchema() and replaced the fixed URL "/" passed to useRouteState() as a parameter with the typed URL pattern url("/shapes/:id"). These changes resulted in params and query being resolved with preciser typing (hover over them in the playground to see their types match the schema). The structure of the code is still pretty much the same, with the route state handling equally similar to React's useState().

This minimalist approach to routing extends beyond managing URL parameters, more of its aspects are covered in the package overview.

By the way, if you're wondering if global/shared state can be managed in the useState()-like manner as well, I've got a post on that, too.

Type-safe routing with less code in React

axtk — Fri, 12 Sep 2025 13:18:32 +0000

In a recent post, I had a code example showcasing a concise way to do routing in React. One of its features is a ternary routing function at(route, x, y) acting similarly to the ternary conditional operator atRoute ? x : y which works equally with components and prop values:

<nav className={at("/", "full", "compact")}>

{at("/", <Intro/>)}
{at(/^\/sections\/(?<id>\d+)\/?$/, ({ params }) => (
  <Section id={params.id}/>
))}

In this code, the params type has a generic shape of Record<string, string | undefined> of an object containing string portions of a string URL. It's sufficient in many cases, but sometimes we might wish for preciser typing. For example, in the code above, params.id matches the pattern of \d+, so it could be an actual number rather than a string.

The discussed approach to routing, in fact, allows for gradual adoption of stricter route typing by incrementally defining URL schemas scaling up from a single component to the entire app.

Let's define a URL schema for our code example to make sure that params.id is typed as a number, and the root URL doesn't accept any params at all:

import { A, useRoute } from "@t8/react-router";
import { createURLSchema } from "url-shape";
import { z } from "zod";

const { url } = createURLSchema({
  "/sections/:id": z.object({
    // path placeholders
    params: z.object({
      id: z.coerce.number(),
    }),
    // similarly, a `query` schema can be added to a route,
    // if necessary
  }),
  "/": z.object({}), // goes without parameters
});

let App = () => {
  let { at } = useRoute();

  // `at(route, x, y)` acts similarly to `atRoute ? x : y`
  return (
    <>
      <nav className={at(url("/"), "full", "compact")}>
        <A href={url("/")}>
          Intro
        </A>{" "}
        <A href={url("/sections/:id", { params: { id: 1 } })}>
          Section 1
        </A>
      </nav>
      {at(url("/"), <Intro/>)}
      {at(url("/sections/:id"), ({ params }) => (
        <Section id={params.id}/>
      ))}
    </>
  );
};

Note that the shapes of the components and the routing function at() remain the same. All what's changed inside the component is that the string and RegExp URL patterns were replaced with the typed URL builder url(). It's using these typed route patterns that makes params.id to be now resolved as a number, and that the route shapes comply with the zod-powered URL schema. (Hover over params and id in the sandbox example to see these types for yourself.)

Although not a requirement, we might want to cover the entire app with type-safe routes. Once we've done that, we might want to disallow plain string and RegExp URLs and URL patterns created outside the URL builder (the url() function) altogether to enforce type-safe routing further on. This can be done by overriding the router's type config in our app's code:

declare module "@t8/react-router" {
  interface Config {
    strict: true;
  }
}

But this is completely optional. Regardless of this setting, a URL schema doesn't have to be defined in a single place, there can be multiple partial URL schemas representing certain portions of the app. This incremental approach to type-safe routing, from a partial URL schema to strict application-wide type safety, makes it easier to adopt and maintain, without impairing the conciseness of the routing code.

This is essentially all what's required to set up type-safe routes with this pretty minimalist approach to routing. See also the package overview for more details on its other aspects.

Lightweight pending state handling in React

axtk — Tue, 09 Sep 2025 19:45:43 +0000

Managing loading state is very common to React apps, but how do we track an async action's state without bringing in a complex lib and major code rewrites?

It would be nice to handle the pending and error states of an async action without rearranging its code and without affecting the existing app's state management, and yet with a clear way to share the action's state with multiple components, when necessary.

To address this task I created a small package called @t8/react-pending. Here's what it looks like in the code:

+ import { usePendingState } from "@t8/react-pending";

  const ItemList = () => {
    const [items, setItems] = useState([]);
+   const [state, withState] = usePendingState("item-list");

    useEffect(() => {
-     fetchItems().then(setItems);
+     withState(fetchItems()).then(setItems);
    }, [fetchItems, withState]);

+   if (!state.complete)
+     return <p>Loading...</p>;

+   if (state.error)
+     return <p>An error occurred</p>;

    return <ul>{items.map(/* ... */)}</ul>;
  };

  const Status = () => {
+   const [state] = usePendingState("item-list");
+
+   return state.complete ? "Done" : "Busy";
  };

Note that the added code doesn't alter the structure of the successful path in the ItemList's internals. The interaction with the component state is also intact. In our example, the data is stored in local state, but it could be stored elsewhere, similarly without being affected by the loading state handling.

The string parameter of the usePendingState() hook assigns a unique key to the particular state that can be used inside other components to refer to that state (like in Status in the example above). When the pending state is only required within a single component, we can just omit the hook's parameter.

So when introducing a complex data fetching lib feels redundant, this small single-purpose lib, can offer a neat, minimalist way to set up the async action state handling, either local or shared, without affecting the app's state.

Routing with less code in React

axtk — Tue, 09 Sep 2025 10:56:35 +0000

The React routers I see here and there leave me wondering: can we actually bring into practice the idea that route-based rendering is a variety of conditional rendering, similar to this:

{atRoute ? x : y}
{atRoute && x}

It would work the same way with components and prop values, and it would make the routing code more concise and semantically clear compared to what routers tend to offer. After playing around with this idea, I still believe it's a way to go.

Here's an example of what I came up with:

let App = () => {
  let { at } = useRoute();

  return (
    <>
      <nav className={at("/", "full", "compact")}>
        <A href="/">Intro</A>{" "}
        <A href="/sections/1">Section 1</A>{" "}
        <A href="/sections/2">Section 2</A>
      </nav>
      {at("/", <Intro/>)}
      {at(/^\/sections\/(?<id>\d+)\/?$/, ({ params }) => (
        <Section id={params.id}/>
      ))}
    </>
  );
};

createRoot(document.querySelector("#app")).render(<App/>);

I'm using a ternary routing function at(route, x, y) as a close semantic equivalent to the ternary conditional operator atRoute ? x : y. The function allows to omit the fallback parameter y when it's effectively undefined (as in at("/", <Intro/>) in the example above) and to pass route parameters to dynamic values (like with <Section id={params.id}/>).

Even without going into detail, this code seems pretty easy to follow. And to write, too.

As a quick comparison, it's worth noting how much more code is required to get a very similar output with TanStack Router (and how more elaborate it is), according to its docs.

View the TanStack Router code example from the TanStack docs

import { StrictMode } from 'react'
import ReactDOM from 'react-dom/client'
import {
  Outlet,
  RouterProvider,
  Link,
  createRouter,
  createRoute,
  createRootRoute,
} from '@tanstack/react-router'
import { TanStackRouterDevtools } from '@tanstack/react-router-devtools'

const rootRoute = createRootRoute({
  component: () => (
    <>
      <div className="p-2 flex gap-2">
        <Link to="/" className="[&.active]:font-bold">
          Home
        </Link>{' '}
        <Link to="/about" className="[&.active]:font-bold">
          About
        </Link>
      </div>
      <hr />
      <Outlet />
      <TanStackRouterDevtools />
    </>
  ),
})

const indexRoute = createRoute({
  getParentRoute: () => rootRoute,
  path: '/',
  component: function Index() {
    return (
      <div className="p-2">
        <h3>Welcome Home!</h3>
      </div>
    )
  },
})

const aboutRoute = createRoute({
  getParentRoute: () => rootRoute,
  path: '/about',
  component: function About() {
    return <div className="p-2">Hello from About!</div>
  },
})

const routeTree = rootRoute.addChildren([indexRoute, aboutRoute])

const router = createRouter({ routeTree })

declare module '@tanstack/react-router' {
  interface Register {
    router: typeof router
  }
}

const rootElement = document.getElementById('app')!
if (!rootElement.innerHTML) {
  const root = ReactDOM.createRoot(rootElement)
  root.render(
    <StrictMode>
      <RouterProvider router={router} />
    </StrictMode>,
  )
}

As seen from our first code snippet, the route-matching function at(route, x, y) also works the same way with both components and prop values (like with <Intro/> and the <nav>'s className). By contrast, the file-based, component-based, and config-based approaches are focused on component rendering while prop values have to be handled differently.

Since at(route, x, y) is an ordinary stateless function, at() calls aren't coupled together, they don't have to maintain a certain order, they don't have to be grouped in a single component (and they also can be, as in our small example above), pretty much like any other conditional rendering. This makes the routing function at() very flexible and fit for arbitrary route-based logic (more so than other approaches to routing).

Based on this approach, I created @t8/react-router. With all its minimalism and straightforwardness, it brings the routing code closer to common patterns and makes it more intuitive in other aspects, too: with regard to the route link API, navigation API, SSR, lazy routes, URL parameters state, type safety. These topics are covered in more detail in the package overview.

Quick exercise of designing a minimal shared state API in React

axtk — Mon, 08 Sep 2025 16:38:25 +0000

There are a number of state management libs described as minimal or bare-bones, but are they indeed? Let's run through this exercise and see how these libs match the minimal design. In fact, designing minimal shared state will require just a few steps.

First, we'll lift the initial value of the local state to a shared location:

  // non-interactive shared initial state
+ let AppContext = createContext(0);

  let Counter = () => {
    // local state, invisible to other components
-   let [count, setCount] = useState(0);
+   let [count, setCount] = useState(useContext(AppContext));

    // render
  };

The initial state value can now be seen by other components via the Context, but setCount() won't affect the shared value yet. To make the shared state interactive we can pack it into a container object, we'll call it a store, exposing a state setter, so we don't have to manually add a value setter to the Context. To unpack the state value from the store and subscribe to its changes inside the component we'll add a useStore() hook. With the store and the hook, we'll get a full-fledged shared state setup:

  // full-fledged interactive shared state
+ let AppContext = createContext(new Store(0));
- let AppContext = createContext(0);

  let Counter = () => {
+   let [count, setCount] = useStore(useContext(AppContext));
-   let [count, setCount] = useState(useContext(AppContext));

    // render
  };

Now, calling setCount() will update the shared count value. Note how this shared state setup is similar to React's useState(): we've got the same API for reading and updating the count value.

With the store and the hook, we've got a minimal shared state setup that is also familiar and quick to migrate to from local state. If we're good with useState() for local state, useStore() can be just as good for shared state.

Compared to this setup, other approaches look more verbose. With Zustand, we're going to have something like the following, as suggested by the docs:

const useBearStore = create((set) => ({
  bears: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
  removeAllBears: () => set({ bears: 0 }),
}));

const Controls = () => {
  const increasePopulation = useBearStore((state) => state.increasePopulation);
  return <button onClick={increasePopulation}>one up</button>;
};

The Zustand approach is a bit concerning in its encouraging of mixing state and actions, which blurs the semantic boundary between the data and the behavior. In practice, such mixed state will require extra workarounds to make it serializable for SSR, and it carries around the entire action set while it can be never used to that extent in a particular component.

The minimal approach discussed above doesn't raise any of these concerns: the data in the store is clearly separated from behavior, and it's pretty straightforward with SSR. In this approach, the Zustand example can be very similar to a useState() setup:

+ const AppContext = createContext(new Store({ bears: 0 }));

  const Controls = () => {
-   const [state, setState] = useState({ bears: 0 });
+   const [state, setState] = useStore(useContext(AppContext));

    const increasePopulation = () => {
      setState(state => ({ ...state, bears: state.bears + 1 }));
    };

    return <button onClick={increasePopulation}>one up</button>;
  };

Based on this approach and its minimalist spirit, I created @t8/react-store. It exports such Store and useStore() completing this exercise. In addition to the discussed, the package description covers its common use cases including a single-store and multistore setup (both being perfectly legit), filtering store state updates, with some live examples.

Prefer let over const (not the other way around)

axtk — Sat, 03 May 2025 15:33:39 +0000

Preferring const over let has become sort of mainstream (often enforced with a linting rule), but that actually breaks their semantics and discards the developer's intention.

Semantically, const is a developer's way to communicate to other devs that the variable shouldn't be changed, not that it isn't changed in the current version of code. The developer's intention that a variable shouldn't be changed can't be inferred solely from static analysis of the code, unlike the variable's property of currently being unchanged.

Automatically replacing let with const results in the loss of the distinction between constants specifically marked as never-to-be-changed by a developer with variables that happen to be unchanged, but not inherently unchangeable.

For currently unchanged variables, the prefer const rule also introduces an unnecessary diff when the variable has to be reassigned in a later code change, by converting const to let. And since any const can now be easily switched to let, devs are deprived of a simple way to convey the meaning that a variable is not supposed to be modified.

To fix this, let should be preferred over const by default, with const reserved to things that devs decide shouldn't be changed.