2.0.0-beta.14: Server `dynamic()` renders nothing for Promise component sources

[yumemi-thomas]

Describe the bug

In Solid 2.0.0-beta.14, client dynamic() supports Promise component sources through async-aware computation, and the public server dynamic() type also accepts Promise<T>.

However, server dynamic() renders nothing when the source returns a Promise, even when using the async SSR API.

This creates a server/client/API mismatch for async component sources. It is not a Solid 1.x regression; the issue is that the Solid 2 API appears to allow this shape, but the server path silently renders empty output.

Your Example Website or App

https://stackblitz.com/edit/solidjs-templates-tsjnp9k3?file=src%2Fentry-server.tsx

Steps to Reproduce the Bug or Issue

1. Open the StackBlitz terminal.
2. Run npm run repro.
3. Inspect the rendered string.

""

Expected behavior

Server dynamic() should either support Promise component sources in a way that matches the client, or produce an explicit unsupported diagnostic/error.

Because this repro uses renderToStringAsync, the server can wait for the Promise source.

If Promise sources are supported on the server, expected output shape:

<span>Hello Ada</span>

Screenshots or Videos

No response

Platform

• OS: macOS
• Runtime: Node.js
• Version: current next at d8921ac1

Additional context

This appears related to packages/solid-web/server/index.ts: server dynamic() reads the source synchronously and handles only function/string values:

const comp = source(),
  t = typeof comp;

if (comp) {
  if (t === "function") return comp(props);
  else if (t === "string") return ssrElement(comp, props, undefined, true);
}

When source() returns a Promise, typeof comp is "object", so the server returns undefined instead of suspending/waiting or producing an explicit unsupported diagnostic.

[tsushanth]

Worked through this against next (HEAD at d8921ac). Repro lands exactly where you said — packages/solid-web/server/index.ts:53 only branches on typeof comp === "function" and typeof comp === "string", so a Promise source falls off the end and the render-effect produces an empty slot.

The shape closest to what the surrounding async-SSR primitives already do (packages/solid/src/server/component.ts:79, lazy()) is to wrap the resolved access in createMemo({ sync: true }), surface NotReadyError(p) while the promise is unresolved, and call (sharedConfig as any).context.block(p.then(() => {})) so renderToStringAsync / renderToStream know to wait for the promise before flushing.

Sketch (the relevant slice — the rest of dynamic() is unchanged):

const p = comp as Promise<T> & { v?: T };
if (p.v === undefined) {
  p.then((v: T) => { p.v = v; });
  const ctx = (sharedConfig as any).context;
  if (ctx?.async) ctx.block(p.then(() => {}));
}
return createMemo(
  () => {
    if (p.v === undefined) throw new NotReadyError(p);
    return (p.v as Function)(props);
  },
  { sync: true } as any
);

I prototyped this and threw a regression at ssr-stream.spec.tsx:

test("server dynamic() awaits Promise component sources (#2779)", async () => {
  function Inner(props: { name: string }) { return <span>Hello {props.name}</span>; }
  function App() {
    const Comp = dynamic<Component<{ name: string }>>(
      () => asyncValue(Inner as Component<{ name: string }>, 10)
    );
    return <Comp name="Ada" />;
  }
  const html = await renderComplete(() => <App />);
  expect(html).toContain("Hello Ada");
});

The test still rendered an empty string with the patch applied — NotReadyError bubbles out of the memo but the renderer doesn't seem to await it from this position the same way it does for lazy()'s output. lazy() differs in two ways I couldn't fully reconcile from the outside: (1) it preloads via LazyHome.preload!() in the existing tests, so p.v is already populated when the memo first reads; (2) the memo is returned to a JSX position created by createComponent(Lazy, props), while dynamic() wraps its memo in runWithOwner(memoOwner, …) inside an outer arrow that's then createComponent'd again. There's almost certainly an owner-scoping detail that makes the lazy() shape participate in the async pipeline but not the dynamic() one.

Happy to send a PR if a maintainer can sanity-check the right place to thread the block — either inside dynamic() directly, or by routing the promise through createComponent(props => …) the same way lazy() does — or to leave this issue as a starting point if it needs deeper SSR plumbing first.