Explore React Compiler and Integrate with examples

[Muhammad-Bin-Ali]

Integrate React Compiler across all examples

Summary

• Adds babel-plugin-react-compiler to all 9 React examples via the @vitejs/plugin-react Babel config
• Removes the enable_ctx_exports compatibility flag from the codemode example's wrangler.jsonc
• All 17 examples verified to start successfully

Changes

Example	File
codemode	vite.config.ts
playground	vite.config.ts
mcp	vite.config.ts
mcp-client	vite.config.ts
tictactoe	vite.config.ts
workflows	vite.config.ts
resumable-stream-chat	vite.config.ts
a2a	vite.config.ts
cross-domain	vite.config.ts

How to integrate React Compiler

1. Install the Babel plugin as a dev dependency (already in root package.json):

   npm install -D babel-plugin-react-compiler@latest
   

2. Add it to the react() plugin's Babel config in vite.config.ts:

   react({
     babel: {
       plugins: ["babel-plugin-react-compiler"]
     }
   })

3. No other configuration is needed — React 19 is the primary target, and the compiler works out of the box with zero config.
   For full details, see the official introduction: https://react.dev/learn/react-compiler/introduction

Linting (optional)

An ESLint plugin is available to identify components the compiler cannot optimize:

npm install -D eslint-plugin-react-hooks@latest

When the ESLint rule reports an error, it means the compiler will skip optimizing that specific component or hook. This is safe — the compiler continues optimizing everything else. You don't need to fix all violations immediately; address them at your own pace to gradually increase the number of optimized components.

Note: This repo uses Oxlint, not ESLint, so this plugin is not currently wired up. It can be run alongside Oxlint if full Rules-of-React validation is desired.

Verifying the compiler is working

Components optimized by React Compiler will show a "Memo ✨" badge in React DevTools:

1. Install the React Developer Tools browser extension
2. Open your app in development mode (npm run start)
3. Open React DevTools (Components tab)
4. Look for the ✨ emoji next to component names
   If the compiler is working:

• Components will show a "Memo ✨" badge in React DevTools
• Expensive calculations will be automatically memoized
• No manual useMemo is required

---

Generated by OpenCode

[changeset-bot]

⚠️ No Changeset found

Latest commit: 080d1d5

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/agents@909

commit: 080d1d5

[deathbyknowledge]

Looks good, just one small change

[threepointone]

@Muhammad-Bin-Ali what did you learn from doing this? I see you've changed the configs, but could we simplify any react code? What are the goals/benefits of adding the compiler?

[Muhammad-Bin-Ali]

@Muhammad-Bin-Ali what did you learn from doing this? I see you've changed the configs, but could we simplify any react code? What are the goals/benefits of adding the compiler?

From what I gathered, the React Compiler primarily focuses on adding memoization where needed. In our examples, there's not many, if any, places to simplify code because we don't use useMemo anywhere. That being said, there are a few places where we do use useMemo within our packages and that could probably be simplified. I'm hesitant to make concrete claims here because it's heavily dependent on the context in which the code is written.

I still think we could benefit to adding it to our packages folder as well. That way, future developers don't have to actively think about memoization and as long as good React practices are being followed, React Compiler + the linter will take care of the rest. It's a pretty easy setup so I think it's worth it.

[threepointone]

I would love to see an experiment where we take an example with useMemo, run it without the compiler, then run it with, and see what's different. why are we using useMemo in those places?
a danger is that if we recommend (ie, just use react compiler) in our examples, and if someone takes our code and tries it in their code, without setting up the compiler, their code would break. in what way?

[Muhammad-Bin-Ali]

I would love to see an experiment where we take an example with useMemo, run it without the compiler, then run it with, and see what's different. why are we using useMemo in those places? a danger is that if we recommend (ie, just use react compiler) in our examples, and if someone takes our code and tries it in their code, without setting up the compiler, their code would break. in what way?

Hmmm good point. Let me see what I can set up.

Also, there are places in our examples where we can simplify the code a little. React compiler also removes the need for adding useCallback manually. There are a few places in our examples where useCallback is used.

[Muhammad-Bin-Ali]

I added a demo to this branch. It also outputs the JSX intermediate representation. After running it with and without compiler, there should be two files, one with compiled output and one uncompiled.

TLDR of differences;

The compiler adds a per-component cache array that is checked before values/functions/elements are accessed.

Future implications:

Based on some online research, people's mileage with integrating React compiler will vary. For example, there's a Tanstack Tables library that React Compiler breaks, but can easily be fixed by adding no use memo to the component that uses that library. Another problem that can arise when developing future examples is that setting up the compiler vs. not doing so can lead to infinite renders (code snippet below)

// BEFORE: works everywhere, with or without the compiler

const refreshPermissions = useCallback(async () => {
  const result = await agent.call("getPermissions");
  setIsReadonly(!result.canEdit);
}, [agent, connected]);

useEffect(() => {
  refreshPermissions();
}, [refreshPermissions]);


//=====================================================

// AFTER: someone removes useCallback in a cleanup PR

// "the compiler handles memoization now"
const refreshPermissions = async () => {
  const result = await agent.call("getPermissions");
  setIsReadonly(!result.canEdit);
};

useEffect(() => {
  refreshPermissions();
}, [refreshPermissions]);
// ❌ Without the compiler: new function ref every render
//    → effect re-fires → calls getPermissions → setState
//    → re-render → new ref → effect re-fires → infinite loop

If we choose to remove the useCallback usage in our examples, it shouldn't lead to any issues with or without the compiler. That doesn't guarantee that future examples won't lead to problems however. In fact, I can easily see a situation like above taking place if a user chooses not (or can't for some reason) use React Compiler.

Lastly, I'd be very hesitant to make any changes to the existing code useCallback and useMemo usage in packages though. It could be beneficial for development moving forward but I can imagine that it could uncover a slew of untraceable bugs if we start modifying existing code.

I amend my previous claim of it being a good addition to the codebase. It's hard to say if it's worth the problems that it could lead to in the future. It could be a good addition if we had browser-based behaviour testing, but even then, experientially, not all UI behaviour can be tested programatically.

[threepointone]

Yeah I was concerned this would be the outcome. React folks trying. to be a bit too clever here. I'm going to block this from landing while we figure it out. Thanks so much for diving into this @Muhammad-Bin-Ali, it was worth it.