Frontend on sbgrl.me

Should you use React Strict Mode in Next.js?

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Tue, 03 Mar 2026 17:34:00 +0800

If you’re not familiar with React StrictMode, you’re probably not using a framework like Next.js that enables it by default. Strict Mode aims to help you find bugs during development. But it feels more like a band-aid that can reveal bugs or hide them, especially when mixing with server-side rendering (SSR).

In this post, I will assume you’re using SSR and Strict Mode too as they are usually enabled by default with Next.js.

Enter the rabbit hole
#

Now let’s suppose you write the following component, that renders a simple <time /> markup for a given date. Nothing fancy:

export default function LocalTime({ date }: { date: Date }) {
 const isoString = date.toISOString();

 return <time dateTime={isoString}>{date.toLocaleString()}</time>;
}

Let’s say you also have a simple home page, in your typical React application:

import LocalTime from "./local-time";

export default function Home() {
 return (
 <main>
 It is <LocalTime date={new Date("02/03/2026, 10:00 AM")} />
 </main>
 );
}

If your application uses SSR, what you will see always depends on your locale and on the time zone of the server; in this case, with an en-US locale and a UTC timezone, the server will render the following page, even in development:

It is 2/3/2026, 10:00:00 AM

However, that’s usually not what you want for your clients. Let’s say your client lives in Singapore, they should expect to see a time in a different timezone (GMT+8 in the case of Singapore). If you’re a bit experienced, you know your component must run on the client, and there’s a "use client;" directive in React that ensures a component can be an entry point to client rendering. You update the LocalTime component:

"use client"; // new directive

export default function LocalTime({ date }: { date: Date }) {
 const isoString = date.toISOString();

 return <time dateTime={isoString}>{date.toLocaleString()}</time>;
}

Your development server hot-reloads and this time you see:

It is 2/3/2026, 6:00:00 PM

Success! However, when you refresh the page, you notice there’s a flicker: the UTC time shows first, then the local time appears. You pull up the console, and you see a pretty large error message:

Uncaught Error: Hydration failed because the server rendered text didn't match the client. As a result this tree will be regenerated on the client. This can happen if a SSR-ed Client Component used:

- A server/client branch `if (typeof window !== 'undefined')`.
- Variable input such as `Date.now()` or `Math.random()` which changes each time it's called.
- Date formatting in a user's locale which doesn't match the server.
- External changing data without sending a snapshot of it along with the HTML.
- Invalid HTML tag nesting.

We’ve hit a classic issue with React SSR/CSR: hydration mismatch due to a time zone difference between the server and the client. And more importantly, you might not have noticed that error at all. The flicker might not have caught your attention, you might not have looked at the console.

You might just have deployed it to production. And to your surprise, once in production the page would show the UTC time only. It seems the component did not run on the client. Not a great user experience:

It is 2/3/2026, 10:00:00 AM

In reality, there was no reason for your component to re-render on the client again after hydration. This happened in development only due to React Strict Mode, so we’ve been led down the wrong path; thinking the application worked where it didn’t. You think this example is contrived? At Canterly, we have already faced 3 scenarios similar to this one; each time React Strict Mode was hiding an issue.

The reasoning behind Strict Mode
#

React brings a flavor of functional programming (FP) to UI. In FP, when the output of a function is defined only by its input, and it has no side effects, we call it a pure function. The React equivalent means that the rendering of a component should be idempotent: it depends only on the component properties, its state and its context. These 3 sources of information are the rendering inputs in React; you should not use any other inputs.

That is not to say React does not handle side effects. However, you should confine side effects to events handlers, and in case you can’t find a suitable event handler for your side effect, React dedicates a whole phase of its update to side effects which you declare in the use*Effect() hooks. The steps below are an over-simplification of an update with React (more about it here):

If there are no updates to component inputs, go to the last step;
Render updated components;
Run side effects;
Return to the top;
Commit changes to the DOM.

Idempotency allows React to track component changes by looking only at their inputs. However, it’s easy to break idempotency if you unknowingly use an external input, modify properties incorrectly or rely on a variable during rendering that is not provided through its properties, state or context.

To help uncover these issues, React introduced Strict Mode. Wrapping your component in <StrictMode> adds an extra render on mount and after the side effects run, to check that rendering was not impacted:

If there are no updates to component inputs, go to the last step;
Render updated components;
Run declared side effects;
Strict mode: render all components once more and check there are no differences with the output in 2.
Return to the top;
Commit changes to the DOM.

If your React component is pure, then that extra render should be idempotent and similar to the first.

False positives with Strict Mode
#

Returning to our example: the first server-side render produces an incorrect UTC time, which could have been caught if it was not immediately redrawn by the extra Strict Mode render that occurred when React mounted the component. Instead, the developer saw the local time.

This little example illustrates that this approach is just as likely to catch a bug as to hide one, since Strict Mode can lead to false positives. Especially if you’re not careful with checking hydration issues.

It’s worth noting that a more careful developer could also catch the hydration mismatch. And they might be tempted to address the locale & time zone hydration mismatch by simply silencing it, since this component does not have any children:

"use client";

export default function LocalTime({ date }: { date: Date }) {
 const isoString = date.toISOString();

 return (
 <time dateTime={isoString} suppressHydrationWarning>
 {date.toLocaleString()}
 </time>
 );
}

Perhaps unexpectedly, once the component uses the property suppressHydrationWarning, the UTC time rendered server side re-appears and is not replaced by the local time in development. Even in the presence of Strict Mode, the component is not regenerated again. This could have revealed the error again; but requires employing a property that is usually discouraged.

Beyond Strict Mode
#

Since React 18, the React Compiler has grown a new linter. I highly recommend the React Compiler ESLint plugin. While it does not address all the objectives of Strict Mode, there’s a significant amount of overlap between the two tools. In my own usage, I have found that the linter helps me better with identifying violations of the Rules of React.

Unfortunately, when it comes to our little example, the linter does not identify that date.toLocaleString() requires a time zone and a locale that are not declared as input to the component. The linter is still a work in progress; I hope that these limitations will eventually be addressed.

I will leave you with a version of the component that follows the Rules of React (note that this version will not scale well if you have a lot of components to render):

"use client";

import { useEffect, useEffectEvent, useState } from "react";

export default function LocalTime({ date }: { date: Date }) {
 const [formattedDate, setFormattedDate] = useState(
 // Fix a locale and a time zone for idempotency
 date.toLocaleString("en-US", { timeZone: "UTC" }),
 );
 const isoString = date.toISOString();

 const onMount = useEffectEvent(() => {
 setFormattedDate(date.toLocaleString());
 });
 useEffect(() => {
 onMount();
 }, []);

 return <time dateTime={isoString}>{formattedDate}</time>;
}

This may seem a little complicated for a component that just renders a date without any interactions; but remember that there’s a hidden side effect in the original rendering. And unfortunately, in this specific scenario, Strict Mode put us on the wrong path.

One of the selling points of Strict Mode is that it will help reveal the issues with components that violate the Rules of React. But I would argue that if the issues can’t be found without Strict Mode, then you might as well just ignore them: your component is probably too simple to care about them. Otherwise, you should always pay attention to hydration issues and ensure your project uses the React Compiler ESLint plugin.

Interop makes my day joyful

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Tue, 17 Feb 2026 20:06:00 +0800

Check out Interop 2026. It has been one of the driving force behind aligning browser’s compatibility across the market and towards the standards.

I used to hate UI development, and by far I hated web development the most. The incompatibility across browsers has been a plague on web development. I think my feelings are widely echoed across the community, as something you would just have to put up with. I generally stayed away from doing any web development.

For me, things started to really turn around circa 2017. When I joined Grab around that time and discovered caniuse.com or React 16, web development started to feel less like a pile of hacks. Structure and organized community efforts started to emerge.

The launch of the web-platform-tests has undoubtedly been a major step forward. Thanks to this project and others, browser compatibility is generally not a concern in my daily web development routine. I can safely say there’s real joy to web development nowadays, and LLMs have made it easier than ever to get into.

Introducing @sbougerel/eslint-plugin-next-use-client-boundary

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Sat, 14 Feb 2026 17:46:00 +0800

In my last post I spoke about releasing an ESLint plugin to lint the serialization of 'use client' module entries. I’ve spend a few hours with Claude code to get this done and published on npmjs.org. I’ll probably come back in another post on the experience there (Some gains, some losses). I’ve just started a branch on my product to use the plugin, looking forward to see if it’s useful to others.

Don't abuse 'use client'

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Sat, 31 Jan 2026 17:56:00 +0800

I see 'use client' used too often in our own code base, and it seems to be a matter of confusion elsewhere too: devs don’t understand 'use client' or don’t want to get into it. Let me give a quick explanation of why you should not use it everywhere and hopefully, by the end of this post, you’ll have at least understood what it is not for.

'use client' indicates that a client module can be called within server modules. No more no less. That means 'use client' modules have some restrictions, because they can sit at the server-client boundary:

When a server evaluated module imports values from a 'use client' module, the values must either be a React component or supported serializable prop values to be passed to a Client Component. Any other use case will throw an exception.

(Source: React reference)

The thing is: most types are serializable, so you don’t generally see an issue with putting 'use client' everywhere. But one commonly used type is not: plain simple functions. It should make intuitive sense: a reference to a function is meaningless at the server-client boundary (unless it is a server action).

In practice: if your reactive client component exposes events to its parents, like onSubmit and onCancel in the component below, that means we expect the parents to be client component themselves.

 export default function LineItemForm({
 account,
 onSubmit,
 onCancel,
 }: {
 account: string;
 onSubmit?: (data: LineItemData) => void;
 onCancel?: () => void;
 }) {

How could it be otherwise? The function onSubmit or onCancel could never cross the client-server boundary. Thus, you can remember now:

When an exported client component has properties that are not serializable, like functions, its module should not start with 'use client'.

Now, you may be thinking: “But adding 'use client' does not hurt anything, right?” Ever taken painkillers when you don’t need it? It’s the same reasoning: it does not harm, but at the critical moment where you need to feel pain, you’re suddenly numb to it.

Without 'use client' at the top of that component, the compiler will not let you call that client component from a server component. But with an incorrect 'use client' the compiler will just obey and assume you’ve made sure the properties are serializable without checking, and misusing that component in server components could result in runtime errors.

Unfortunately, I cannot find any linter that lints this. There is however a dynamic warning provided by the typescript-language-server: Props must be serializable for components in the "use client" entry file. Adding a linter for this would be an interesting project.

Pino log instrumentation with Next.js 16

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Sun, 04 Jan 2026 11:39:00 +0800

Recently at Canterly, we migrated from Next.js 14 to Next.js 16. In that process, we also switched from webpack to turbopack. This was a great speed improvement that came with some surprises. In particular, log instrumentation via next-logger now triggered a failure during compilation. I had been wanting to replace it anyway, since all it does is to patch console to use Pino instead (It also patches log functions in Next.js next/dist/build/output/log, which is redundant since these functions use console too). So instead, I patched console on my own. This is simpler and allows us to keep control over the instrumentation, rather than obfuscating the process with an additional dependency.

This is what we have now in instrumentation.ts:

export async function register() {
 if (process.env.NEXT_RUNTIME === 'nodejs') {
 const instrumentation = await import('./instrumentation-nodejs');
 await instrumentation.register();
 }
}

We’ve replaced next-logger.config.cjs with our own logger.ts which is a straight forward port:

import { LoggerOptions, pino } from 'pino';

let pinoOptions: LoggerOptions = {
 level: 'warn',
};

if (process.env.NODE_ENV !== 'production') {
 pinoOptions = {
 level: 'info',
 transport: {
 target: 'pino-pretty',
 },
 };
}

export const logger = pino(pinoOptions);

And in instrumentation-nodejs.ts:

import type { LogFn } from 'pino';

async function instrumentLogging() {
 // NextJS also patches `console` functions during development for better
 // debugging; bypass instrumentation unless the environment
 // variable CANTERLY_INSTRUMENTATION is "true"
 if (
 process.env.NODE_ENV === 'development' &&
 process.env.CANTERLY_INSTRUMENTATION !== 'true'
 ) {
 return;
 }

 const loggerModule = await import('./logger');

 const wrapLogger = (method: LogFn, ...args: unknown[]) => {
 if (args.length === 0) {
 return;
 }
 if (args.length === 1) {
 return method(args[0]);
 }
 // Converts usual Console usage to Pino's meta patterns.
 if (
 args.length === 2 &&
 typeof args[0] === 'object' &&
 args[0] !== null &&
 typeof args[1] === 'string'
 ) {
 return method(args[0], args[1]);
 }
 if (typeof args[0] === 'string') {
 return method({ consoleArgs: args.slice(1) }, args[0]);
 }
 return method({ consoleArgs: args });
 };

 const consoleLogger = loggerModule.logger.child({ name: 'console' });
 (['error', 'warn', 'debug', 'info', 'log', 'trace'] as const).forEach(
 (level) => {
 if (level === 'log') {
 console[level] = (...args) =>
 wrapLogger(consoleLogger.info.bind(consoleLogger), ...args);
 } else {
 console[level] = (...args) =>
 wrapLogger(consoleLogger[level].bind(consoleLogger), ...args);
 }
 },
 );
}

export async function register() {
 await instrumentLogging();
}

And that’s it. This instrumentation does not just replace next-logger, it improves on it. With next-logger, the following console call…

console.log("Log without interpolation", valueA, valueB, valueC)

…would be patched to the Pino call…

logger.log("Log without interpolation", valueA, valueB, valueC)

…but that would lose logging data: when the first argument is a string message, Pino will only keep other arguments when they get interpolated. This new instrumentation preserves the additional arguments, by treating them as a mergingObject.

Now, when our application starts, we can immediately see the additional arguments in the logs, as soon as instrumentation kicks in (We use pino-pretty as the default transport during development):

npm run dev
> ...
> env TZ=UTC next dev

▲ Next.js 16.1.1 (Turbopack)
- Local: http://localhost:3000
- Network: http://...
- Environments: .env.local

✓ Starting...
[03:23:14.265] INFO (console/28071): ✓ Ready in 1439ms
[03:23:14.447] WARN (console/28071): [auth][warn][debug-enabled]
 consoleArgs: [
 "Read more: https://warnings.authjs.dev"
 ]

NextJS revalidateTag won't work if it's not called in an awaited promise

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Thu, 18 Dec 2025 18:37:00 +0800

Using unstable_cache extensions or "use cache" if you’re on NextJS16, you can leverage revalidateTag to invalidate cache across cached calls. However, I noticed today that these won’t work in a route handler that is not async. And I’m not yet sure why.

This was my original (simplified) route handler:

export async function POST(req: Request) {
 try {
 void someTask();
 return NextResponse.json({ done: true });
 } catch (err) {
 return new NextResponse(`Internal error`, {
 status: 500,
 });
 }
}

Note that someTask returns a Promise which I didn’t await initially: the caller only needed to know that someTask was called, not that it succeeded. However, it became evident someTask didn’t behave properly.

someTask gets a list of subscriptions and updates them progressively. After each update, it re-validates cache entries associated with the Subscription tag:

const cachedFindOutdatedSubscriptions = unstable_cache(
 findOutdatedSubscriptions,
 undefined, // Unused (For additional keys)
 {
 tags: ["Subscription"],
 },
);

export default async function someTask() {
 const subscriptions = await cachedFindOutdatedSubscriptions();

 for (const subscription of subscriptions) {
 await updateSubscription(subscription);
 revalidateTag('Subscription');
 }
}

The function cachedFindOutdatedSubscriptions returns subscriptions from a cache entry also tagged with Subscription. You would therefore expect that across repeated calls to this route, the subscriptions array becomes empty when no new subscriptions are created.

This is not what happened; the same subscriptions got reprocessed every single time, served from the cache. As if revalidateTag was not called.

Interestingly, the fix is simply to await the call to someTask in the route handler:

 export async function POST(req: Request) {
 try {
- void someTask();
+ await someTask();
 return NextResponse.json({ done: true });
 } catch (err) {
 return new NextResponse(`Internal error`, {
 status: 500,
 });
 }
 }

After reading the code for unstable_cache, I got the intuition for the fix. I’m not sure of what is exactly happening under the hood yet, but I think it has to do with the lifetime of the request’s context. I’ll return to this once I understand it properly.