Replies: 3 comments 1 reply
-
// lib/deps.ts
export type { default as React } from "https://esm.sh/react@17.0.2";// lib/ssr.tsx
import type { React } from "./deps.ts";
export const ssr =
(deps: {
renderToStaticMarkup: (element: React.ReactElement) => string;
renderToString: (element: React.ReactElement) => string;
}) =>
(app: React.ReactElement): string => {
return "todo";
};// in an app
ctx.response.body = ssr(ReactDOMServer)(<App />); |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Btw, should we use this or not? Does it have any advantage? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
You can check out https://alephjs.org/ , they're building a whole framework for React in Deno just like Next.js (which is really awesome). |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I decided to start this discussion because I didn't find any official recommendations.
For example, how to switch dev and production builds?
How to write a React component library in Deno?
Without peerDependencies, how to ensure only one instance of React in an app?
As for 3), one idea I have is to pass the whole React object to component factories.
Such a component library would import only React namespace type. What do you think?
As I see it, the only alternative to peerDependendies is "types as a contract".
Beta Was this translation helpful? Give feedback.
All reactions