React Server Components support

[fellipeutaka]

Hello everyone!
I'm a user of the Phosphor icons library, and I'm writing to discuss the possibility of adding support for server components.

Currently, the library only supports client components because the icons use forwardRef and useContext. However, I believe that adding support for server components would greatly improve the accessibility and performance of the library, especially for server-rendered applications.

I would like to propose that we work together to add support for server components to the Phosphor icon library. I understand that this would require some changes to the library's architecture, but I believe that the benefits would be worth the effort.

What do you think? Are you open to discussing this further and exploring the possibility of adding support for server components in Phosphor?

Thank you for your time and consideration.

[rektdeckard]

Hi @fellipeutaka, I totally understand your concern. I'm open to any solution that doesn't involve a breaking change to any APIs, but I don't think we would consider taking away IconContext for existing users (at least the consumer-facing API of it, I'm open to changing how it works internally).

I have not built anything with Next13+ or RSC, but it seems like it could be possible with a non-React-based state management library?

[rektdeckard]

forwardRef, on the other hand, I have no idea how to get around.

[rektdeckard]

Also, I'm curious if this is an actual issue, or more just a principle thing? Icons are, 99.9% of the time, leaf nodes in the React tree. What is the real overhead of shipping a bit of JavaScript per icon vs. a marginal amount less of pre-rendered HTML?

[rektdeckard]

Also, just to clarify, are you saying that Phosphor doesn't work when used in server components, or just that it is an obligate client component and you would like for it to be rendered on the server? I'd definitely focus on fixing the former right away if that is an issue.

[fellipeutaka]

Yes, Phosphor doesn't work when used in server components, because they use APIs that are only available in client components, which in this case are forwardRef and useContext. So for example, if I have a footer component on my page that doesn't have any interactivity, I'm forced to turn my footer component into a client component. Let me bring you an example with code.

Homepage:

import { Footer } from "@/components/Footer";

export default function Home() {
  return (
    <>
      <main className="h-screen flex items-end p-4">
        <h1 className="font-bold">Main page content</h1>
      </main>
      <Footer />
    </>
  );
}

Footer component:

"use client";

import Link from "next/link";
import { Phone, Envelope, MapPin } from "@phosphor-icons/react";

export function Footer() {
  return (
    <footer className="bg-zinc-900 p-12 text-center flex flex-col gap-4">
      <div className="flex justify-around">
        <div className="flex flex-col items-center gap-4">
          <Phone
            size={36}
            weight="bold"
            className="bg-violet-500 rounded-full p-2"
          />
          <p>+55 (11) 99999-9999</p>
        </div>
        <div className="flex flex-col items-center gap-4">
          <Envelope
            size={36}
            weight="bold"
            className="bg-violet-500 rounded-full p-2"
          />
          <p>[email protected]</p>
        </div>
        <div className="flex flex-col items-center gap-4">
          <MapPin
            size={36}
            weight="bold"
            className="bg-violet-500 rounded-full p-2"
          />
          <p>Test Street, City, Country</p>
        </div>
      </div>
      <hr />
      <div className="flex gap-4">
        <Link href="/service">Terms of service</Link>
        <Link href="/privacy">Privacy policy</Link>
      </div>
    </footer>
  );
}

Now see an image of what this footer would look like:

However, it has a problem. If I don't use the "use client" in my footer component, I'll get the following error:

I was thinking of creating a ServerIconBase.tsx in the lib folder that doesn't use forwardRef and useContext to be able to use icons in server components.

[rektdeckard]

I understand the issue and what's needed to make it work, but I don't see how it's possible to eliminate forwardRef. Each icon needs to be one itself, in addition to IconBase, or whatever wrapper is used. There's no other way to pass the ref down to the final DOM element properly.

[fellipeutaka]

Sorry I messed up. Actually forwardRef can be used in Server Components. I created an Input component that uses the forwardRef and didn't really have any problems.

Homepage:

import { Footer } from "@/components/Footer";
import { Input } from "@/components/Input";

export default function Home() {
  return (
    <>
      <main className="h-screen flex items-end p-4">
        <h1 className="font-bold">Main page content</h1>
        <Input />
      </main>
      <Footer />
    </>
  );
}

Input component:

import { InputHTMLAttributes, forwardRef } from "react";

export const Input = forwardRef<
  HTMLInputElement,
  InputHTMLAttributes<HTMLInputElement>
>((props, ref) => {
  return (
    <input
      className="bg-zinc-900 border-none outline-none text-white p-4 rounded-lg"
      ref={ref}
      {...props}
    />
  );
});

Input.displayName = "Input";

So if the real problem is the useContext of IconBase.tsx, wouldn't it be possible to create a ServerIconBase.tsx?

[rektdeckard]

Ah, should be doable then. I'll experiment with it tonight.

[rektdeckard]

I have a working solution with #47 but I have no clue whether it is a good idea to be shipping non-isomorphic components like this. The same DOM nodes should ultimately be rendered by both a ServerBase and ClientBase, but this may be violating some rule of RSC I'm not aware of. I also plan to do some performance testing to see if there is an impact, and if this is event worthwhile.

[rektdeckard]

An experimental build is now live on NPM under version 2.1.3, and also installable under the @next tag. Check out #64 for details on usage. We plan to mainstream this soon, once we've had time to get any feedback.