Hi,

We released Waku v1.0.0-beta.0 recently.

Check out: https://waku.gg/blog/waku-v1-beta

Waku is a minimal React framework, and by that I mean it’s minimal from both a framework user perspective and a framework developer perspective.

Config-Based Router

For the router, we first developed a config-based router, which is a lower-level API. We then developed a wrapper layer to implement a file-system-based router.

It’s basically a one-to-one mapping. For example, with the config router, we do:

createPage({
  path: '/hello',
  component: () => <h1>Hello</h1>,
  render: 'dynamic',t
})

File-System Router

For the same route, what we do with the file-system router is:

// ./src/pages/hello.tsx
export default function() {
  return <h1>Hello</h1>
}

export const getConfig = async () => {
  return {
    render: 'dynamic',
  };
};

The path and component parts are automatically inferred, and the rest is provided by the getConfig function.

Capability-wise, the config router and the file-system router are equivalent. It’s just a stylistic difference.

If you are interested, check out the source code, which is only 172 loc.

Happy coding.

Hi,

It was more than one year ago when we released Jotai v2.12.0.

https://github.com/pmndrs/jotai/releases/tag/v2.12.0

It introduced a new idea to expose some internals so that ecosystem libraries can extend Jotai's core capabilities. It was collaborative work with David Maskasky, who is the maintainer of jotai-effect, jotai-scope, and so on.

Why Building Blocks

I didn't like extending the store after creation, because that would cause some mismatches, like having two different capabilities over time. What I chose was to accept customization at the time of building a new store. I call this customization method the building blocks of a store.

The initial implementation was somewhat limited. It didn't provide full customization, and the API was a little bit hard to deal with.

Over time, we've improved it. Around v2.15.0, we mostly finished it, and the API became both flexible and safe, or hard to misuse.

Performance Regression

A long time later, at least for me, someone reported that there seemed to be a performance regression. The major reason was the use of WeakMap, which was meant to improve the flexibility of building blocks.

See more: https://github.com/pmndrs/jotai/pull/3280

We iterated on ideas to solve it, and I decided to go with one idea, which is not super clean, but fits with my mental model. Basically, instead of using WeakMap, it now passes everything as parameters.

Toward Jotai v3

Many users don't need to understand the subtlety. But I just wanted to share that there was some history behind it.

Jotai v2.20.0 was released a couple of days ago.

https://github.com/pmndrs/jotai/releases/tag/v2.20.0

Now, I'm ready to think about Jotai v3.

Happy coding.

Hi,

Is RSC a data protocol or an architectural design? I had a similar question when I started developing Waku, or even before that.

Early Motivation

As a library author, my interest was the serialization algorithm. Actually, I made a library called react-worker-components, which includes a homegrown serialization algorithm supporting references. So, my first goal with Waku was to wire up RSC's serialization capability into something usable. It was like a DEV-only playground for RSC.

Adding Production Build Support

Later, it introduced bundling thanks to Vite and many custom plugins, which can generate a production build.

Around that time, while discussing with someone at the React team, I noticed RSC was a broader concept. For example, an RSC framework shouldn't encourage some bad practices like client-server waterfalls, which is one of the biggest problems RSC was trying to solve. So, I changed Waku's API so that it eased, or more or less forced, a single round-trip request and response API.

Library Interoperability

Another example is library interoperability. There's a library called react-tweet. It's a pure RSC library and is not tied to Next.js. Many fixes have been done in Waku to support it and similar libraries.

Another library to tackle was the AI SDK. It uses RSC extensively, and it was challenging, but we made it work.

RSC as Architecture

Nowadays, React docs include RSC stuff, and it's clearer than before that RSC is not just serialization logic, but the entire architecture with best practices. That said, I think there is still room for more documentation.

Waku should be a full RSC framework. If you find some bugs, feel free to report them.

Happy coding.

Hi,

Last month, I visited Paris, France, to attend the conference React Paris 2026. It's a long journey from Japan, but visiting a place far away gives me some excitement.

My Talk

I gave a talk at the conference on the first day about my history of developing state management libraries. They were not created randomly. I had clear goals, and it happened to become multiple libraries.

Watch the Talk

You can watch my talk on YouTube:

Happy coding.

Hi,

AI-assisted coding is great, without a doubt. But when it comes to OSS contributions, the story is a bit more complicated.

The Problem

For my OSS projects, when I receive a PR, I need to look into it. At that point, I do not know how much AI assistance was used. Let us take an extreme case. If a PR is 100% AI-generated, I need to review it instead of the contributor, and I need to ask the contributor to fix it if necessary. That feels like a real waste.

I should just ask the AI directly. Or, what is even better is to ask the AI from the start. Then I know the full context, what AI I am using, what I asked, and how I should control it. Having a human contributor is pure overhead.

Of course, that is not the case if the original PR is perfect. But that is unlikely, because not everything is in the code base and the docs. Although small, there is something in my brain that is not exposed. It is probably impossible, because I do not know what it is. It is like my preference, but I do not know it until I get asked.

What Contributors Can Do

That was an extreme case, but even if the contributor did some review of the AI-generated code, things do not change a lot. Unless humans do more work, it does not make sense. That is only possible for those who can do the work without AI.

So, what do I think would work? I think after reporting issues, sending a PR with a failing test would help, but solutions should not be included. The failing test can be assisted by AI, as long as the human reviews it, and the test is human-readable, representing the spec.

Final Thoughts

This idea might be controversial, but it is what I feel now. It can change when things change, which can happen pretty soon in this AI era.

Happy coding.

Hi,

Today, I'd like to talk about community contributions. In the past couple of weeks, several PRs from community contributors landed across my projects. I think this is worth sharing.

Zustand v5.0.11

I released Zustand v5.0.11 on February 1st. It is a patch release, but all three fixes came from community contributors.

The devtools middleware got better typing. The persist middleware was fixed to not rely on the global localStorage directly. This matters in environments where localStorage is not available. And the immer middleware typing was improved for the slices pattern.

None of these are flashy changes. They are the kind of improvements that quietly make a library more reliable.

I should also mention v5.0.10, which included a fix for a race condition during concurrent rehydrate calls in the persist middleware. That PR required patience from the contributor, who waited through the review process. The result is solid.

Excalidraw Animate

Someone submitted Playwright E2E tests for excalidraw-animate. I requested some changes during review. After the fixes, I merged it. It is good to see testing infrastructure being added to this project by someone other than me.

Waku

In Waku, a new contributor made their first contribution by fixing middleware auto-discovery to exclude test files. A Spanish-language learning resource was contributed and merged. And a Netlify dynamic routes bug was fixed by a community member.

Why This Matters

I maintain these projects, but I cannot catch everything. Middleware edge cases, test infrastructure, documentation in other languages. These contributions come from people using the libraries in ways I do not. That is what makes open source better than what any single developer can do.

If you want to contribute to any of these projects, there are always open discussions and issues to work on. Do not hesitate.

Happy coding.

Hi,

Last year, one of my activities was thinking about how to monetize my OSS products, and it is still a topic this year too. The software itself is free, so what could we sell? I guess documents for OSS can be info products. But people do not often buy OSS documents, right? My hypothesis is that when AI-assisted coding becomes more common, AI can buy info products to accomplish tasks. A human might confirm it, or they might not even notice.

Jotai Techniques

For such a future, I was planning to create "Jotai Techniques", which would be a collection of examples to showcase good uses of Jotai. It is kind of an experiment in how LLMs can utilize it. I also explored the use of MCP servers to provide the info product with authentication. Check out https://github.com/jotaijs/jotai-mcp-server.

Why it did not take off

However, the idea of "Jotai Techniques" never took off. There are several reasons.

For one, I am not good at writing docs, and I enjoy coding if I have time. Another is that I was not sure how to make a convincing case for this idea. I could try a small task with AI-assisted coding with and without "Jotai Techniques", and compare the results. But AI is evolving too fast, and the evaluation would get stale too soon. Lastly, it is still not the age where AI buys something behind the scenes. It will take more time.

Jotai Skills

So, I gave up this idea. Now that agent skills are getting popular, I think we should work on "Jotai Skills". That is very close to my original idea of "Jotai Techniques" last year, only partially though.

Unfortunately, I am not motivated to lead this project alone, so I decided to call for collaborators:
https://github.com/pmndrs/jotai/discussions/3221

I look forward to it.

Happy coding.

Hi,

We just released Waku v1.0.0-alpha.0. Our public API has been stable for some time, and it is ready for wider adoption. Check out our blog post:

Waku 1.0 (alpha) — Waku

Waku's public APIs are now marked as stable.

waku.gg/blog/waku-v1-alpha

It has been almost three years since I started this project. It was originally called Wakuwork:

Twitter tweet

It started as my personal experiment, but soon after that, some collaborators joined, and we decided to aim for a production-ready framework. Waku v0.18 was released two years ago:

Introducing Waku — Waku

Learn about the minimal React framework and how it enables RSC features.

waku.gg/blog/introducing-waku

We have received a lot of feedback since then, and we have improved our APIs and implementations. I’m proud of it, and I appreciate all contributors.

Happy coding.

Hi,

I was interviewed for a podcast episode, and it is now available on YouTube. Check it out here.

This was one of my unusual talks, because I did not prepare much for the interview. Usually, I prepare scripts for my talks, because I’m not great at speaking spontaneously, not only in English, but also in my native tongue. So, this one was special.

In the past, I did some podcast episodes, and I wrote scripts in advance. Check out this blog post for my past talks, and my previous newsletter for my latest conference talk, in case you missed it.

Happy coding.

Hi,

On October 3, 2025, I gave a talk at the React Alicante 2025 conference. To my memory, this was probably the longest conference talk I’ve ever done.

Talk Overview

The talk covers a basic introduction to Waku, and why I created it. I also talk about what motivated me to start developing a new React framework. I showed an experimental library called waku-jotai, which was kind of my original motivation.

Recording

Check out the recording video here.

Try Waku

If you have not tried Waku yet, give it a spin. Hope you like it.

Happy coding.

Hi,

About four years ago, I started seriously considering monetizing OSS. Generally speaking, I develop OSS for my personal fun. It is not a job someone requested me to do, but something that I enjoy developing without other forces. I do not need to get paid for fun.

However, there are several issues for me. One is that I need to pay bills and prepare for the future. So, I need to earn money. Contract work helps, but usually it is not very related to my OSS projects. (BTW, I am open to an opportunity that is related to them.) So, it would be great if I can earn money directly from my OSS projects. Another issue is that while I enjoy very much starting a new project, maintaining it is a different story. I am proud of projects going well and I do not mean that I dislike maintaining them. That said, maintaining projects involves many non-coding tasks (while I love coding), and there are many chores and sometimes stressful things. So, it would be great to have some incentives, in this case, money.

Past Attempts

A long time ago, I created some courses, tutorials and a book. It was a good experience, but it took much time. I realized that I should spend more time on coding than creating courses. In 2022, I tried something different. I created a simple info product (like a tutorial video) that is not like a full course, but something much easier to create. The point of it was that the fee was not only for the info product itself, but also for supporting the project. However, it was more or less a one-time small donation and it does not last long unless we keep promoting it, which is too much work for me.

I think the general problem is that we should not expect individual developers to donate from their own pocket money. I think we should get sponsorship from companies who inherently get benefits from the OSS projects. That is kind of obvious, and someone advised me in the past as well. So, I decided to take on another challenge.

Using GitHub Sponsors

This time, I use GitHub Sponsors. I have already configured my GitHub Sponsors dashboard, but I did not pay much attention to sponsor tiers. Especially, I did not provide any specific rewards. This is because my assumption is that my product is my outcome. However, in recent years, I have learned that rewards are actually important for sponsorship.

The sponsorship program is called "Zustand Banner Sponsorship" and the idea is simple. We put sponsor logos in our README.md. I think it is pretty normal for sponsorship rewards.

How the Banner Works

As I do not want to change README.md every time sponsors change, I made a small website to show the list of sponsors and provide a banner image showing all sponsor logos, which will be embedded in README.md. I made this website with Waku and hosted it on GitHub Pages.

If you are interested, check out the banner image at the Zustand repository and click the banner.

If you are interested in sponsoring, click the "How to become a sponsor" button.

Happy coding.

Hi,

I just released Waku v0.27.1 this week. It has various fixes and improvements, but I want to emphasize one big improvement. It is a patch release because we do not change any APIs. What is changed is the behavior of static rendering.

Static and Dynamic Parts

There had been a limitation that when you mix a static part and a dynamic part in a page, the static part rerenders in some cases. For example, suppose we have a static layout and dynamic pages.

/static-layout/dynamic-page-1
/static-layout/dynamic-page-2

In terms of HTML, these pages are dynamic anyway, and they always rerender entirely.

However, with RSC, the components look like this:

<StaticLayout>
  <DynamicPage1 />
</StaticLayout>

<StaticLayout>
  <DynamicPage2 />
</StaticLayout>

And we should be able to reuse the static layout if we navigate to dynamic-page-2 from dynamic-page-1.

Previous Limitation

Previously this was already possible when navigating from dynamic-page-1 to dynamic-page-2. StaticLayout did not rerender with soft navigation.

However, there was a limitation at the initial load. When we first opened dynamic-page-1, it always rendered StaticLayout. And if we did a hard navigation, which is the same as the initial load, it also always rendered.

What Changed in v0.27.1

With v0.27.1, we refactored the internals and made sure that StaticLayout only renders once at build time. The technical challenge was finding a way to serialize the static parts of RSC, restore them, and merge them with dynamic parts. The rest was the effort to rework everything with the new architecture, which was not a trivial task.

I am proud of the outcome, and I expect the new behavior matches what developers intuitively expect. Static means static and only evaluated once.

Why Now

I knew this limitation in Waku existed for a while, but the fix was prioritized after we introduced the Slices API. The new behavior is important for static slices, and now static slices are more powerful.

Please give the new version of Waku a try and share your thoughts.

https://waku.gg

Happy coding.

Hi,

Waku v0.25.0 has been released with a new API. It's called Slices. The Slices API is inspired by Gatsby's similar API, at least we took the name. However, I don't think every detail is the same. We used to have layout and page components, and now, with the new API, slice components.

Layouts and Pages

Layouts and pages are based on routing. For the /foo route, we use:

src/pages/_layout.tsx
src/pages/foo/_layout.tsx
src/pages/foo/index.tsx

Slices

Slices are isolated from routing. You can define one like:

src/pages/_slices/bar.tsx

It isn’t served based on routing. We need to explicitly use it in other components. The way we use the slice is as simple as:

<Slice id="bar" />

Use Cases

So, what are the use cases? I think there are at least three.

1. Shared Components

We could use the slice in both / and /foo routes. When we navigate from / to /foo, we can reuse the cached slice component. This makes sense if either / or /foo is dynamic, and the slice component is static. It works only with client navigation (or soft navigation).

2. Mixing Dynamic and Static Parts

While it is technically possible with layouts and the (group) syntax, using the Slices API can be more straightforward. If your page is static, you can embed a dynamic slice to mix static and dynamic parts. If your page is dynamic, you can embed a static slice. You can also embed multiple static or dynamic slices regardless of the page type.

3. Lazy Slices

This one is a bit different. We call these lazy slices. You use the lazy prop like:

<Slice id="bar" lazy fallback="Loading..." />

Lazy slices are fetched after the initial rendering and hydration are done. One use case is having a static page with a lazy dynamic slice. If we build the page, it generates HTML statically, which can be placed on a CDN. The dynamic slice is fetched from the server after the client finishes rendering the initial page from the CDN. This is what I call “Waku Islands.”

Limitations and Future Exploration

We still have more use cases to explore, but these three are the initial motivations.

One caveat with slices is that if a slice is not used as a lazy slice and is embedded in a page, the page’s config must include all IDs of slices used in that page. This is a designed limitation. It is a bit tedious, but I hope it is not too much.

For more information, check out the announcement post at https://waku.gg/blog/rethinking-fine-grained-components.

Hope you enjoy Waku with the new API.

Happy coding.

Hi,

I’ve been developing Waku for about 2.5 years now. Waku is a minimal React framework focusing on React Server Components. When I started building it, there was no tech stack I could rely on. I began with a naive Node.js solution using two workers, because the second worker was required to handle the react-server condition.

Moving to a single JS runtime

Later, I wanted to avoid a Node.js dependency, and moved to code transformation so that everything could run on a single JS runtime, not necessarily Node.js. That’s when Hono and Vite came into the picture.

At that point, Waku’s dev server still used two Vite processes for the react-server condition.

Vite’s RSC plugin to the rescue

The long-awaited breakthrough arrived with Vite’s official RSC plugin, including the Environment API. With the Environment API, Waku’s dev server runs on a single Vite instance, and all bundler-specific features are provided by the RSC plugin. This was a great move, because my motivation was never about bundler internals, even though we spent several years building our own Vite-based bundler to support RSC.

Learn more: https://waku.gg/blog/migration-to-vite-plugin-rsc

Waku’s core and what’s next

With Vite handling RSC natively, most bundler-specific logic lives outside of Waku itself. Waku’s core is now just a minimal API layer. Beyond this core, Waku provides:

• a handy CLI

• an extensible server

• an opinionated router based on the minimal API

Now that Vite handles RSC, we can explore more features around React Server Components.

Happy coding.

Hi,

Valtio is a proxy-based state management library for React—but it also works in plain JavaScript. Its primary goal is to provide a global-state solution for React, not to solve JavaScript reactivity in general. That said, its vanilla API remains quite useful outside React.

Valtio in Vanilla JavaScript

For example, you can subscribe to changes in a proxy state:

import { proxy, subscribe } from 'valtio/vanilla';

const state = proxy({ count: 0 });
subscribe(state, () => {
  console.log('Count changed:', state.count);
});

state.count++; // → "Count changed: 1"

And you can take snapshots of state over time:

import { proxy, snapshot } from 'valtio/vanilla';

const state = proxy({ count: 0 });
const snap1 = snapshot(state);
state.count++;
const snap2 = snapshot(state);

console.log(snap1, snap2); // → { count: 0 } { count: 1 }

Snapshots are essential for React integration, but there are use cases in vanilla JavaScript, such as keeping a history of changes.

What’s Missing Compared to “Reactive Frameworks”

I’m not very familiar with all the reactive frameworks, so please correct me if I’ve gotten anything wrong. What seems to be missing in Valtio, compared to other reactive frameworks, are two common patterns:

1. Effects with usage tracking

2. Computed values with usage tracking

1. Effects with Usage Tracking

Currently, you subscribe by passing the state and a callback:

const state = proxy({ count: 0 });
subscribe(state, () => {
  console.log('Count changed:', state.count);
});

A reactive-style effect would track only the properties you access, without specifying the state object explicitly:

const state = proxy({ count: 0 });
effect(() => {
  console.log('Count changed:', state.count);
});

state.count++; // → "Count changed: 1"

This also supports multiple source states without extra arguments.

2. Computed Values with Usage Tracking

Computed works similarly; while effect doesn’t return anything, computed returns a new proxy state. It looks like this:

const state = proxy({ count: 0 });

const derived = computed({  
  double: () => state.count * 2,
});

console.log(derived.double); // → 0
state.count++;
console.log(derived.double); // → 2

Now, there’s a caveat. Because effects and computed values react immediately to changes, if we want to make multiple updates we need to batch them explicitly. For example:

batch(() => {
  state.count++;
  state.count++;
});

Vanilla Valtio batches by waiting a macrotask, which works for React but not for these reactive primitives.

Introducing valtio-reactive

To fill these gaps, we built valtio-reactive. It implements effect, computed, and batch on top of Valtio:

npm install valtio-reactive

You can import them from the library:

import { effect, computed, batch } from 'valtio-reactive';

“valtio-reactive makes Valtio a reactive library.”

If you’re curious, give it a try and share your feedback. While valtio-reactive isn’t tuned for performance, benchmarking will be interesting too.

Happy coding.

Hi,

First of all, this post is based on uncertainty. Please don’t take any of it too seriously—these are just thoughts and observations based on past work and recent updates from the React team.

The Problem: State and Context in React

Using useState and useContext for state management is still common today—and it works fine until you run into Provider hell. This happens when your component tree is wrapped in multiple context providers, and managing them becomes a chore.

One workaround is to collapse multiple providers into a single component using reduceRight. For example:
🔗 Reference

const CombinedProviders = (props) => {
  const providers = [
    [Provider1, { value: props.value1 }],
    [Provider2, { value: props.value2 }],
    [Provider3, { value: props.value3 }],
  ];
  return providers.reduceRight(
    (children, [Provider, value]) =>
      <Provider {...value}>{children}</Provider>,
    props.children
  );
};

This helps with composition, but not with dynamic state. If you add a new state and context to the tree, it still rerenders the entire subtree.

The First Solution: useContextSelector

To solve this, RFC #119 proposed useContextSelector. Before that landed officially, I released a userland version as the use-context-selector package.

import { createContext, useContextSelector } from 'use-context-selector';

const context = createContext(null);

const Counter1 = () => {
  const count1 = useContextSelector(context, (v) => v[0].count1);
  const setState = useContextSelector(context, (v) => v[1]);
  // ...
};

The main use case here was state. In some cases, that state is held in an external store.

Then Came useSyncExternalStore

React introduced useSyncExternalStore as an official way to subscribe to external state safely in concurrent rendering:

import { useSyncExternalStore } from 'react';
import { todosStore } from './todoStore.js';

function TodosApp() {
  const todos = useSyncExternalStore(
    todosStore.subscribe,
    todosStore.getSnapshot
  );
}

But there’s a caveat: useSyncExternalStore is great for safe external state syncing, but it doesn’t always play well with concurrent rendering.
🔗 See this issue

What About Selectors?

The React team explored context selector solutions but seemed reluctant to embrace selector-based APIs. (Incidentally, I developed Jotai to avoid selectors while still optimizing rendering.)

Instead, the team seems to prefer composable patterns, such as combining useMemo with use(context). I built an experimental userland version using this idea:
🔗 react18-use

import { createContext, use, useMemo } from 'react18-use';

const MyContext = createContext({ foo: '', count: 0 });

const Component = () => {
  const foo = useMemo(() => {
    const { foo } = use(MyContext);
    return foo;
  }, []);
  return <p>Foo: {foo} ({Math.random()})</p>;
};

This approach may work better with React Compiler, and it’s certainly an interesting direction.

Looking Ahead: use(store)

In a recent React blog post, the team introduced a mention of a new API: use(store). It appears to be a concurrent-compatible variant of useSyncExternalStore.

const value = use(store);

We don’t know the details yet. But if it works as intended, I expect use(store) to take priority over useMemo + use(context) patterns—at least in many cases. The two solve different problems, but if the former is widely adopted, the latter might become a niche technique (except where React Compiler makes it particularly useful).

In Conclusion

We don’t know the future yet—these are just some ideas based on where things seem to be going. But it’s always exciting to explore the evolution of patterns in React.

Happy coding.

Hi,

A couple of years ago, I shared a simplified version of Jotai, which helped people understand the basic idea behind its implementation.
🔗 Jotai Core Internals

I think I haven’t done the same for Valtio—until now. Today, I came up with a simplified version of Valtio that only shallowly wraps the object in a proxy.

But Wait—Valtio Is Meant for Deep Proxies

To be clear, the entire purpose of Valtio is to support deep proxies, because that’s what’s needed to comply with React’s immutability contract.

Still, simplifying the core idea can be helpful for learning. So here’s a version that only proxies the top level:

The Simplified Implementation

const SNAPSHOT = Symbol();
const LISTENERS = Symbol();

export const proxy = (baseObj) => {
  let snap = { ...baseObj };
  const listeners = new Set();
  return new Proxy(baseObj, {
    set(target, prop, value, receiver) {
      const result = Reflect.set(target, prop, value, receiver);
      snap = { ...target };
      listeners.forEach((fn) => fn());
      return result;
    },
    get(target, prop, receiver) {
      if (prop === SNAPSHOT) {
        return snap;
      }
      if (prop === LISTENERS) {
        return listeners;
      }
      return Reflect.get(target, prop, receiver);
    },
  });
};

export const snapshot = (p) => p[SNAPSHOT];

export const subscribe = (p, fn) => {
  const listeners = p[LISTENERS];
  listeners.add(fn);
  return () => listeners.delete(fn);
};

import { useCallback, useSyncExternalStore } from 'react';

export const useSnapshot = (p) =>
  useSyncExternalStore(
    useCallback((fn) => subscribe(p, fn), [p]),
    () => snapshot(p),
  );

A Quick Note

I haven’t tested this code, so don’t be surprised if it has bugs. Feel free to try it out and fix whatever doesn’t work.

Happy coding.

Hi,

I've been developing Waku, a React framework, for a couple of years now. It started as my personal project and is now a team effort to explore React Server Components. Check it out: waku.gg

Why I Wanted to Simulate a Slow Network

We use Playwright for end-to-end (E2E) testing in Waku. Ideally, E2E tests should avoid relying on timeouts, and instead wait for specific conditions or signals. But while debugging a feature, I needed to simulate a slow network—specifically to test a pending state handled by useTransition.

Fortunately, there’s a simple way to do this in Playwright, which I’ll share today.

The Solution

Here’s the code we use:
🔗 View on GitHub

await page.route(/.*\/RSC\/.*/, async (route) => {
  await new Promise((r) => setTimeout(r, 100));
  await route.continue();
});

This doesn’t truly slow down the network, but it adds a delay for matching routes. With this, the tests run more stably and let me observe pending UI states more reliably.

A Note on Routing Patterns

Initially, my attempt didn’t work. I tried something like:

await page.route('/RSC/**', async (route) => {

This probably didn’t match the intended URL, though I’m not exactly sure why. I haven’t figured out a good way to debug this pattern matching yet—suggestions are welcome!

Looking Ahead

We’re planning to add more E2E tests to the Waku repository. If you’re interested in contributing, you’re very welcome!

Happy coding.

Hi,

This might be a well-known issue in the React Native community, but recent versions have changed the behavior of module resolution. Don't get me wrong—it’s generally a good move.

Metro and the "exports" Field

Previously, Metro (the bundler used in React Native) didn't support the "exports" field in package.json. It was only available with the opt-in flag unstable_enablePackageExports.

With this flag enabled, Metro starts to understand and respect the "exports" field.

Here’s how it looks in Zustand’s package.json:
🔗 View on GitHub

"exports": {
  "./package.json": "./package.json",
  ".": {
    "import": {
      "types": "./esm/index.d.mts",
      "default": "./esm/index.mjs"
    },
    "default": {
      "types": "./index.d.ts",
      "default": "./index.js"
    }
  },
  "./*": {
    "import": {
      "types": "./esm/*.d.mts",
      "default": "./esm/*.mjs"
    },
    "default": {
      "types": "./*.d.ts",
      "default": "./*.js"
    }
  }
}

Roughly speaking:

• When the import condition is met, the bundler picks the ESM build.

• Otherwise, it falls back to the CJS build.

• If a bundler doesn’t understand the "exports" field at all, it defaults to using CJS.

The Hermes and import.meta Problem

The issue arises because the most-used JavaScript runtime in React Native—Hermes—still does not fully support ESM. It throws an error when encountering import.meta.

🔗 Zustand discussion #1967

My hope was that Hermes would support import.meta before unstable_enablePackageExports became stable.

Unfortunately, that didn't happen.

Now it seems that enablePackageExports is enabled by default, but Hermes still errors on import.meta.

The Workaround

From the discussion, I concluded that using the ESM build in React Native is either a bad idea or simply too early. As a workaround, I added a new condition in the exports field specifically for React Native users.

🔗 Zustand PR #3087

Final Thoughts

What’s concerning is that my original plan was to eventually drop CJS and fully move to ESM. But that now seems like a bad idea if the entire React Native ecosystem still relies on CJS.

Happy coding.

Hi,

I’d like to share something I encountered today. A new discussion was posted in the Valtio repository about an unexpected behavior. It turns out to be a kind of limitation—due to the nature of proxies or the way we use them.

A Simple Example Without Proxies

Let’s start with a plain object example:

const o = {};
const x = (o.x ||= {});
console.log(x === o.x); // ---> true

The idea here is to initialize x if it hasn’t been set yet, and use it in either case. As the last line shows, x and o.x refer to the same object.

Now With Proxies

Things get more interesting when we introduce a proxy. Suppose we use a set handler to wrap any assigned value in another proxy:

const p = new Proxy({}, {
  set(target, key, value) {
    target[key] = new Proxy(value, {});
    return true;
  }
});
const y = (p.y ||= {});
console.log(y === p.y); // ---> false

Here’s where it gets tricky: we expect the proxy to behave transparently, but it doesn’t.
The variable y and p.y are not the same object. Why? Because the expression (p.y ||= {}) does not re-access p.y after the assignment. So the value of y is the raw {}, while p.y is the proxied version.

Re-Evaluating the Expression

If we evaluate the same expression again, it behaves as expected:

const y2 = (p.y ||= {});
console.log(y2 === p.y); // ---> true

Now that p.y is no longer undefined, the expression simply returns p.y, which is already wrapped with a proxy.

Final Thoughts

While this behavior is understandable—especially if you know how proxies work—it’s definitely a little tricky. Explaining it without going into proxy internals can be hard.

Happy coding.