I'm seeing this same thing on 14.0.4. It only works properly when you use dynamic in a component marked with 'use client' or it's children. Doesn't split the chunk if dynamic is used in an RSC to load a client component.

Did you ever figure out a workaround or fix? I'd rather not put a separate client component wrapper around everything i want to split and dynamically load.

I did not figure out a fix no, I've just had to be careful to put the dynamic loading in client components.

It's extra annoying for us though because we're publishing a feature flag SDK that supports conditional dynamic loading based on flags, but currently the helper can only be used in a client component otherwise you risk accidentally sending the unrendered code to the client. For most people that's just a performance concern but for our use case its a risk of potentially leaking unreleased features to people that aren't supposed to see them yet, so it's kind of a big pitfall.

Experiencing the same thing after migrating to app-dir. We have a "modular" website, where an editor can compose a page from 50 different block-types. In NextJS, we have some code which looks like this:

// app/page.tsx
export default function Page() {
  return (
    <>
      {blocks.map(block => <Switch block={block} />
    </>
  );
};

// components/Switch.tsx

export function Switch({ block }) {
  switch (block.type) {
    case "rich-text": {
      const RichText = dynamic(import("../components/RichText.tsx"));
      return <RichText content={block.content} />
    }
     case "image": {
      const Image = dynamic(import("../components/Image.tsx"));
      return <Image src={block.src} />
    }
    case "contact-form": {
      const ContactForm = dynamic(import("../components/ContactForm.tsx"));
      return <ContactForm fields={block.fields} />
    }
    // … etc (times 50)
};

I can't tell you how disappointed I was (after spending hours on migrating to the app-dir) that my client bundle now includes all 50 components on every page.

It's frustrating to know that we could be receiving code-split client components on first byte, taking advantage of parallelization, but instead have to wait for the application to build and call the server again. It's a noticeable delay.

The only solution I've found - but I tell you now, it's a DX nightmare - is wrapping all client components in a wrapper, like that:

// page.ts

const Index = async () => {

  const { isEnabled } = draftMode();
  const { homepage} = await getHomeProps();

  if (!isEnabled) {
    return <Home props={homepage} />;
  } else {
    return <PreviewWrapper props={homepage} />;
  }
};
export default Index;

// PreviewWrapper.ts
'use client';

const PreviewComponent = dynamic(() => import('./PreviewComponent'), {
  loading: () => <Loader/>,
});

const PreviewWrapper: React.FC<{ props: HomepageProps }> = props => {
  return <PreviewComponent {...props} />;
};

export default PreviewWrapper;

export default Index;

We also have like 50 modular components (and a hundred of svg icons!!), and using that method would mean exporting the props type of every component, and writing a wrapper for each of them.

I'm trying to write an HOC or something similar that could do that routing for different components, but dynamic() doesn't accept variables, and might be really difficult to type different props (never used generics for components, but that could be the case).

Something like that:

// ServerDynamicImporter.tsx
'use client';
import dynamic from 'next/dynamic';
import React from 'react';

import Loader from './Loader';
import { PreviewWrapperProps } from './PreviewWrapper';

type Props<T> = {
  props: T;
  component: 'PreviewWrapper' | 'ButtonHeroWeb' | 'SearchMonth';
};

const PreviewWrapper = dynamic(() => import('./PreviewWrapper'), {
  loading: () => <Loader backgroundColor="secondaryLighter" />,
});

const ButtonHeroWeb = dynamic(() => import('../layout/ButtonHeroWeb'));
const SearchListing = dynamic(() => import('./SearchMonth'));

const ServerDynamicImporter = <T,>({ props, component }: Props<T>) => {
  switch (component) {
    case 'PreviewWrapper':
      return <PreviewWrapper {...(props as PreviewWrapperProps)} />;
    case 'ButtonHeroWeb':
      return <ButtonHeroWeb {...(props as { children: string })} />;
    case 'SearchMonth':
      return <SearchListing {...(props as { children: string })} />;
  }
};

export default ServerDynamicImporter;

Then invoked:

// AnyServerComponent.tsx

export const AnyServerComponent: React.ReactNode = () => {
   return (
      <div>
         <ServerDynamicImporter<{ children: string }>
            component={'ButtonHeroWeb'}
            props={{ children:'Button content'}}
         />
         <ServerDynamicImporter<PreviewWrapperProps>
            component="PreviewWrapper"
            props={{ page: home }}
         />
      </div>
   );
}

The only solution I've found - but I tell you now, it's a DX nightmare - is wrapping all client components in a wrapper, like that:

// page.ts

const Index = async () => {

  const { isEnabled } = draftMode();
  const { homepage} = await getHomeProps();

  if (!isEnabled) {
    return <Home props={homepage} />;
  } else {
    return <PreviewWrapper props={homepage} />;
  }
};
export default Index;

// PreviewWrapper.ts
'use client';

const PreviewComponent = dynamic(() => import('./PreviewComponent'), {
  loading: () => <Loader/>,
});

const PreviewWrapper: React.FC<{ props: HomepageProps }> = props => {
  return <PreviewComponent {...props} />;
};

export default PreviewWrapper;

export default Index;

We also have like 50 modular components (and a hundred of svg icons!!), and using that method would mean exporting the props type of every component, and writing a wrapper for each of them.

I'm trying to write an HOC or something similar that could do that routing for different components, but dynamic() doesn't accept variables, and might be really difficult to type different props (never used generics for components, but that could be the case).

That is a good solution. But it opts all the dynamically imported components into client components, which might affect the rendering performance. This is the solution that is not so preferable when we have no choice but to reduce initial bundle size. Both sides have their good and bad things the way i see it. Hope this dynamic import in RSC behavior can be clarified or fixed as soon as possible.

That is a good solution. But it opts all the dynamically imported components into client components, which might affect the rendering performance. This is the solution that is not so preferable when we have no choice but to reduce initial bundle size. Both sides have their good and bad things the way i see it. Hope this dynamic import in RSC behavior can be clarified or fixed as soon as possible.

@WenChun19 this is supposed to be used for components that already are marked as 'client components'. Server components aren't sent to the client anyway, and "hybrid component" (server components imported by client components) are imported dynamically if the component that import them is dynamically imported. So from this point of view there is no difference in performance.
That said, I managed to reduce my initial bundle for home page from this:

To this:

Didn't get any better performance, nor different "page weight" size, according to pagespeed and webpagetest.

I have similar issue in 14.2.4 (canary 15 version also have the same issue) and found only one solution that was mentioned earlier (use wrapper client components).
I agree that it is very strange behavour and it takes me 3 days to understand what is going with next/dynamic.

Any progress?