App router: Content flickering with React.createContext and next/dynamic for SSG/SSR

[KirillEvtushenko]

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/interesting-aryabhata-ckyy6f

To Reproduce

1. Refresh the page
2. Notice that the right block with Client component and RSC inside noticeably flickers

Current vs. Expected behavior

When using next/dynamic with React.createContext, I expect that it will work the same way as without React.createContext.
Please pay attention that initial request with html correctly contains all the needed html. Provider's rerender (recreating of the value object prop) then causes that flickering.

issue.mov

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Wed Feb 21 21:44:43 PST 2024; root:xnu-10063.101.15~2/RELEASE_ARM64_T6000
Binaries:
  Node: 20.10.0
  npm: 10.2.3
  Yarn: 1.22.18
  pnpm: 8.6.5
Relevant Packages:
  next: 14.1.4
  eslint-config-next: 13.5.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

App Router, Dynamic imports (next/dynamic)

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), Vercel (Deployed), Other (Deployed)

Additional context

No response

_NEXT-3074

[huozhi]

Can you try switching dynamic() call to React.lazy() if you're not using ssr: false before we get it fixed? So far there's a suspense boundary warpped there, it probably can be removed in the future if there's no loading specified.

[KirillEvtushenko]

Hey @huozhi ! Thanks for the answer.
I've tried to switch dynamic() calls to lazy():

'use client';

import { lazy } from 'react';

export const ClientComponent = lazy(() => import('./ClientComponent'));
export const ClientComponent2 = lazy(() => import('./ClientComponent2'));
// Other client components imports

However, I get this error (have never seen this kind of error before lol):
Error: Element type is invalid. Received a promise that resolves to: [object Object]. Lazy element type must resolve to a class or function. Did you wrap a component in React.lazy() more than once?

I found the only way to fix it: remove "use client" directive from the registry. But this breaks code-splitting and puts everything to the First load JS

Am I missing something?

[joshwcomeau]

Hi @huozhi!

I'm running into this issue as well, and also thought to try React.lazy(). This does indeed solve the flickering issue, but it causes a regression around the CSS being included on SSR; the awesome work you did to close #62940 isn't applied with React.lazy().

But I'm glad to hear that there's a potential fix, with removing the Suspense boundary when no loading state is provided! I believe this would solve the issue 👍.

[bluebeel]

I can confirm the next/dynamic doesn't work even if done in a "use client" file.
The solution we did for now was using React.lazy where we could. But yeah quite the regression compared to Pages Router ^^'

[KirillEvtushenko]

Moving aside the issue with React.ContextAPI breaking next/dynamic, there is one more “issue” with next/dynamic I want to show. 



We have a number of JAMStack apps built with Next.js, that we are currently moving from Pages router to App router. In CMS we have a content that describes a page -> sections, their order, props etc. Nothing fancy there, quite common approach. To map CMS content to actual components, we use this kind of registry (simplified):


// registry.ts
const ClientComponentLvl1 = dynamic(() => import('./atoms/ClientComponentLvl1'));
const ClientComponentLvl2 = dynamic(() => import('./molecules/ClientComponentLvl2'));
const ClientComponentLvl3 = dynamic(() => import('./organisms/ClientComponentLvl3'));

const components = {
  ClientComponentLvl1,
  ClientComponentLvl2,
  ClientComponentLvl3
}
export const getComponent = (name: keyof typeof components) => components[name]


// page.tsx
import {getComponent}  from "@/components/registry";

const getPageProps = async () => {
  const props = await fetch(`content from CMS`);
  return props;
}

export default async function Page() {
  const props = await getPageProps();

  const Section = getComponent(props.sectionName);

  return (
    <main>
      <Section />
    </main>
  );
}

All pages are built as SSG. If we open some page, HTML loads as it supposed to, we immediately see the content, no CLS. The problem appears if we NAVIGATE to this page using built-in <Link /> component. We don’t see any HTML for "use client" components then and we suffer from noticeable CLS as dynamic components start actually to load dynamically.

Opened directly (looks good): 


direct.mov

Internal navigation (CLS):

navigated.mov

So again: we can directly open the SSG generated page and see the content, but we CAN’T navigate to this page through the app without seeing how it dynamically loads. And this applies only to the ‘use client’ components. RSC is good.
“funny” thing is that the workaround would be to change <Link /> to <a /> tag. Full redirect with reloading of html makes it look much better and smoother, ha.
This behaviour seems wrong. Or do we miss some other way of utilizing JAMStack in Next.js.

[huozhi]

In the repro seems there's a setState call in React context Provider when on mount, which will trigger the re-render of Suspense boundary in next/dynamic that lead to the flicking you saw. We recommend to remove the setState in the context provider.
The reproduction demostrates the issue well but I wonder what's the real-world case as trigger re-render in context Provider will trigger all the re-render in the Suspense boundaries below.