ReactDOMServer as a SSR service

[AriaMoradi]

hey, what are your thoughts on implementing a python bridge to call ReactDOMServer to make the html from inside of the template itself?

I'm thinking about something like this:

{% react_dom_server_render component="ComponentName" props=component_data %}

which will generate something like <h1 id="ComponentName_12344565689">The data was Hello World</h1>

and maybe create a tag for calling React.hydrate() with a tag similar to react_print: {% react_dom_server_print %}

=====

I'm not sure what the performance of such a component will be but it eliminates the need for a seprate SSR engine.

[marteinn]

Thanks for the suggestion @AriaMoradi. I know this is a matter of taste, but I think the best way to treat SSR is to have it as a standalone application (especially when it comes to scaling, caching and monitoring). Thats why we only ship implementations to other SSR services (such as Hypernova),

But, If you would like to build something along the lines of you description, where you perhaps call the js-process directly, there is technically nothing that stops you. Just roll your own SSR service (here's an example of the Hypernova service: https://github.com/Frojd/django-react-templatetags/blob/develop/django_react_templatetags/ssr/hypernova.py) and make that call ReactDOMServer any way you see fit.

Here's more documentation on how you add SSR services https://github.com/Frojd/django-react-templatetags/blob/develop/docs/server-side-rendering.md.

If you think about trying out Hypernova with DRTT I have set up a repo with examples on how to get Hypernova running with DRTT here https://github.com/marteinn/django-react-polls-with-hypernova-examples

I'm marking this as a wontfix, but if you do create a service that calls js directly in thread, let me know, it could be a good third party package!

[AriaMoradi]

I think making this will be useful with the same philosophy that encouraged the django developers to make their it's own server which is good for development time and fast bootstrapping. doing this makes development faster and easier and then you don't have to run your SSR service while you're developing. And as expected you should use a REAL SSR Service at production. For me it's the removing the annoying part of installation, config and running it every time that you need it is much compelling. (as webpack has a no config mode, so maybe this an issue with hastur itself?)

I think maybe running hastur with some default config automatically will make this work.