Deferring dynamic import to client on Next 13 build #44940

What's up with ui? Does that import "react-icons/fa" itself?

I imagine you maybe import a type or something from "react-icons/fa" inside of "ui"?

The ui package wraps around Chakra UI since that library doesn't support server components yet. I'm just exporting the Icon component and IconProps type.

Either way, what I posted doesn't seem to affect bundle size. Did I follow your suggestion incorrectly or are we dealing with a deeper problem?

Well, I reckon the issue is that react-icons/fa might be imported by other module, which means that webpack will bundle it as part of the main bundle, in spite of any dynamic loading.

Oh right, one thing though:

'use client';

import dynamic from 'next/dynamic';
import { useEffect, useState } from 'react';
import { Icon, IconProps } from 'ui';

const lazyIcons =  dynamic(() => import('react-icons/fa'))

const DynamicIcon = ({ icon, ...props }: { icon: string } & IconProps) => {
  const [isVisible, setIsVisible] = useState(false);

  useEffect(() => {
    setIsVisible(true);
  }, []);

  if (!isVisible) return null;

  const iconLoader = (icon) => lazyIcons.then((mod) => mod[icon]));

  return <Icon as={iconLoader(icon)} {...props} />;
};

export default DynamicIcon;

Try with something like that, otherwise, you could load the icons in the useEffect:

'use client';

import dynamic from 'next/dynamic';
import { useEffect, useState } from 'react';
import { Icon, IconProps } from 'ui';

const DynamicIcon = ({ icon, ...props }: { icon: string } & IconProps) => {
  const [icons, setIcons] = useState<typeof import("react-icons/fa") 
   null>(null);

  useEffect(() => {
        dynamic(() => import('react-icons/fa').then((mod) =>  setIcons(mod)));
  }, []);

  if (!icons) return null;


  return <Icon as={icons[icon]} {...props} />;
};

export default DynamicIcon;

Warning the above is pseudocode...

@icyJoseph Neither of these approaches (when corrected from pseudocode) had any effect over the build size. However, I can confirm that this component alone IS responsible for the change, not react-icons itself. I'm using named exports of react-icons elsewhere, which appropriately has only a menial effect on build size. This DynamicIcon component is the one having the outsized effect on bundle size. So I'm convinced we're in the right place, but none of these solutions seem to be doing the trick.

I do wonder if perhaps we're thinking about this in the wrong way. Maybe that First Load JS is accounting for client-side components. Technically speaking, since all of the components that use this component are pre-rendered, I should be able to compute them in advance at build time. In that scenario, I suppose they don't HAVE to be client-side components, right? Since Next 13 was released, I've found it very difficult in some scenarios to determine how components are interpreted by the NextJS compiler. Maybe instead of forcing this to be a client component, we should force it to be a server component?

It really depends on how Next 13 is calculating "First Load JS". That's less clear to me now that server components are a thing.

Alright, I've now read a bit more carefully your comments, and tried out a clean install of create-next-app with react-icons/fa, and I don't really see a 400kB increase on size when using them.

Quite simply, if a component is a server component is pre-rendered Server Side and no JS is shipped for it ~ so to speak, but if you have client components, then a runtime is loaded, once, for all of the client components, plus their dependencies.

When I run bundle analyzer on my toy app, I see that the client side contains about 8kB of react-icons/fa, whereas the server (node.js) side bundle has 400kB ~ ish. That's just bringing in one icon though:

"use client";

import { FaBeer } from "react-icons/fa";

export const ClientComponent = () => {
  return (
    <div>
      <p>Beer:</p>
      <p>
        <FaBeer />
      </p>
    </div>
  );
};

Now let's do a dynamic import of the whole thing:

"use client";

import { useEffect, useState } from "react";

export const ClientComponent = () => {
  const [icons, setIcons] = useState<typeof import("react-icons/fa") | null>(
    null
  );

  useEffect(() => {
    import("react-icons/fa").then((mod) => setIcons(mod)); // import-cost now complains about this!
  }, []);

  if (!icons) return null;

  const Icon = icons["FaBeer"];
  return (
    <div>
      <p>Beer:</p>

      <p>
        <Icon />
      </p>
    </div>
  );
};

And when running the bundle analyzer I now see a huge chunk of 419.82 kB, which is the entire icon library.

The Chrome DevTools for coverage benchmark, indicate a 1.3 MB file, with 98% unused Javascript has been downloaded, and yes, it is the Icon library!

Interestingly, this is a separate chunk, with only icons.

Let's try the same in pages only, and we'll see the same issue! (Notice the hash name of the icon bundle is the same, but I've now moved the "client component" as a good ol' page)

So now we know the Server Components, appDir has nothing to do with it. There's a fundamental issue with what we are trying to achieve.

import { useEffect, useState } from "react";

const IconPage = () => {
  const [icons, setIcons] = useState<typeof import("react-icons/fa") | null>(
    null
  );

  useEffect(() => {
    import("react-icons/fa").then((mod) => setIcons(mod));
  }, []);

  if (!icons) return null;

  const Icon = icons["FaBeer"];
  return (
    <div>
      <p>Beer:</p>

      <p>
        <Icon />
      </p>
    </div>
  );
};

export default IconPage;

The root issue is that when we create a dynamic import, we bundle up the entire module into a single file. When we do import('react-icons/fa') we are throwing away the entire module separation they've made for us, and we are telling Webpack to bundle it all up into one chunk. Surely the chunk is server asynchronously and only when the client requests it, but it is huge!

What we want is to make a request per icon chunk!

A Hack

We can abuse dynamic imports, by breaking a rule, we will not have statically defined dynamic imports, well let it be a wild card, this has implications that you'll have to deal with yourself.

First you must install: @react-icons/all-files

Warning: Bundle analyzer timing will sky rocket with this hack

import { useEffect, useState } from "react";

import type { IconType } from "@react-icons/all-files";

const IconPage = ({ iconName = "FaBeer" }: { iconName: string }) => {
  const [icon, setIcon] = useState<
    { [key in typeof iconName]: IconType } | null
  >(null);

  useEffect(() => {
    import(`@react-icons/all-files/fa/${iconName}.js`).then((mod) =>
      setIcon(mod)
    );
  }, [iconName]);

  if (!icon) return null;

  const Icon = icon[iconName];

  return (
    <div>
      <p>Beer:</p>

      <p>
        <Icon />
      </p>
    </div>
  );
};

export default IconPage;

And now if we build... get ready for this...

Every little box in this screenshot is an icon!

Now I check the Chrome DevTools:

Only 172kB transferred.

Let's move that to Server Components

"use client";

import { useEffect, useState } from "react";

import type { IconType } from "@react-icons/all-files";

const NoIcon = () => <i>No Icon</i>;

const Icons = () => {
  const [iconName, setIconName] = useState("FaBeer");
  const [icon, setIcon] = useState<
    { [key in typeof iconName]: IconType } | null
  >(null);

  useEffect(() => {
    import(`@react-icons/all-files/fa/${iconName}.js`)
      .then((mod) => setIcon(mod))
      .catch((e) => {/* silence the error */});
  }, [iconName]);

  if (!icon) return null;

  const Icon = icon[iconName] || NoIcon;

  return (
    <div>
      <input
        type="text"
        onChange={(e) => setIconName(e.target.value)}
        value={iconName}
      />

      <p>Icon:</p>

      <p>
        <Icon />
      </p>
    </div>
  );
};

export default Icons;

And we get this nice result:

Each icon is about 1.5kB ~

Unhacking the hack

If you could produce a list of all icons that will be used, then you could make a map that goes iconName -> lazy import, so that these are statically known at build time, and then you'd select from that map as needed.

Btw I choose beer because that's the example icon I found on their page.