3 ms·
Like the idea, but would love more information about the difference to performing the following steps: - use a React SSG, obviously without client-side code -
by moritzwarhier 3y ago
Like the idea, but would love more information about the difference to performing the following steps:
- use a React SSG, obviously without client-side code
- use an existing "print to PDF" engine to render the resulting HTML+CSS
At first glance, this seems to be using JSX only. Ain't it possible to use JSX and fully static components without even using React? Is that what Astro is doing?
I'm a bit underinformed here, but it would be nice if the landing page would outline a bit more clearly what parts of React are used here and how (it also mentions fetching data dynamically to feed the components).
The PDFs hopefully don't contain JS interactivity and the data fetching is done at the top level of the component tree, before rendering the result to HTML (or does this skip HTML+CSS as an intermediate completely?), right?
The landing page looks great, would just love some more thorough explanation on what parts of React this uses and how.
Also, is there a JSX-based SSG that completely excludes client-side JS and is not made by Facebook? Would be interesting.
All that being said, it's truly interesting how much appeal JSX still has as a templating language focusing on JSON-serializable data structures, completely ignoring React's original value proposition of reactivity.
- Titou325 3y agoHey, Titouan part of the Onedoc team. You are absolutely correct and most existing tools do leverage a browser (sometimes headless) to convert HTML to PDF. However, browser's CSS print specification implementation is severely lacking and layout options are poor to say the least. There is a second option using libraries that abstract part of the layout process such as react-pdf but although it uses the JSX syntax, you can't port existing HTML components easily. Onedoc is able to take HTML + CSS as well, quite similarly to what you can do with Resend. React is mostly an abstraction layer that allows you to take advantage of all the existing SSG toolset (e.g. charts, existing frontend components, ...) without having to write things from scratch. The process is thus indeed similar to Astro if you omit any client: directives. We have put up a small comparison at onedoclabs.com/why-onedoc to show a bit better what capabilities this opens. Hope this clarifies things!
- moritzwarhier 3y agoThanks for the detailed reply, much appreciates. Sounds like React JSX rendering while omitting any client-side JS could benefit from forking off React itself, no? OTOH it's up to the user of course to choose components that do not require client JS and diagnose problems caused by components relying on it.
- Titou325 3y agoIt could probably but I believe maintaining these two would probably be more work than accepting the drawbacks. Another advantage of supporting full-fledged React is that (in the near future) we can allow Javascript in the rendering engine, meaning that components can recompute themselves and pull their own data in. We will see where that goes!
- moritzwarhier 3y agoYes, that sounds interesting, and I sincerely hope that a future release of React manages to simplify use cases such as SSG with build-time JS.