-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSR Runtime for hyper
and lit
#148
Comments
The particular use-case that brought this up was attempting to perform just-in-time server-side rendering in Deno with Solid. Ideally, I'd like to use a proper
My next best bet was to try using /** @jsxImportSource https://esm.sh/solid-js@1.4.7/h */
import {
Document,
Element,
Node,
} from "https://deno.land/x/deno_dom/deno-dom-wasm.ts";
import { renderToString } from "https://esm.sh/solid-js/web/dist/server";
// @ts-ignore
globalThis.document = new Document();
// @ts-ignore
globalThis.Element = Element;
// @ts-ignore
globalThis.SVGElement = Element;
// @ts-ignore
globalThis.Node = Node;
const App = () => {
return <div>Hello world!</div>;
};
console.log(renderToString(() => <App />)); Given also that all three of Edit: replacing
|
SSR and even hydratable client both use different transforms than the standard client and leverage additional runtime behaviors. Hydration for a framework like Solid has been pretty tricky to figure out. I suspect the Tagged Template literals would be possible but not sure the HyperScript is. I'm soon embarking into research to do more complex transformation for both the SSR and Hydration cases to support more performant approaches. In any case good issue to track. But any runtime that cares about the combination of performance and ergonomics should consider supporting custom transforms or they will be leaving a ton on the table, both in server runtime perf and most importantly the ability for these solutions to do optimal hydration. |
As the title says. Currently
hyper
andlit
only run on browser runtime, so if one were to use these on server-side, users aren't able to use SSR API fromdom-expressions
The text was updated successfully, but these errors were encountered: