fix(rsc): fix server deserialization?

[hi-ogawa]

• follow up fix(rsc): client element as bound arg encryption #905

Instead of creating registerClientReference on the fly, we should technically pull original "use client" module on server to preserve module export identity.

Well, actually I'm not sure how this difference would manifest on user land e.g.

// on server
import { TestClient } from "./client";

const original = <TestClient />
const serialized = renderToReadableStream(original, ...);
const deserialized = createFromReadableStream(stream, ...);

// what's the meaningful difference for users on "server"?
// - original vs deserialized
// the actual client module identity will be restored on "client" (browser/ssr) in the same way

and it sounds fine to not go so strict and we can postpone?

todo

• build
  • how not to break tree-shaking?
    • need to emitChunk? but that would force rollup not to tree shake unused client exports?
  • "*" key allows easier encoding? don't think so https://github.com/vercel/next.js/blob/f30797f8fb682ff7777018ddab077647f844d9d0/packages/next/src/build/webpack/plugins/flight-manifest-plugin.ts#L432-L447
    • it looks like it's assuming relevant server chunks are loaded when deserialization.
  • can we keep track of registerClientReference calls during runtime?
    • this sounds possible, but we need to ensure they are registered when deserialization (i.e. if server is code split, we need to execute those chunks.)
    • the same approach might essentially work for dev.
• dev

[hi-ogawa]

• fix(rsc): fix server deserialization? #906 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.