So there are two different kinds of rendering React that finch can do: using renderToStaticMarkup to be able to use React essentially just for templating, and using renderToString so you can have some HTML containing the output of renderToString(some_component) and also some JS that calls ReactDOM.hydrate() on that element. The idea is that you can have a traditional site consisting of multiple HTML pages rather than one big JS bundle, where React is used for some components but it’s not a React-controlled SPA (this is how e.g. Facebook use it). And furthermore by doing renderToString at compile time then hydrating at runtime rather than rendering at runtime, the HTML for your components will be visible as soon as the HTML of the page is loaded rather than after the JS is loaded and executed.
This second part was what I was talking about in terms of the motivation. As far as I can tell, the only existing options for doing this were calling renderToString manually and copying and pasting the result into your HTML, or using a framework like Next.js. I didn’t really want to learn/use a whole JS framework just for this, plus most frameworks seem to use “server side rendering” where you have to serve your frontend from a Node server whereas I like my frontend to be entirely static so it can be served from blob storage/a CDN. So I basically made this to automate the manual process (the relevant filter does just call React functions via Node; I didn’t reimplement them in OCaml). Then since I’d written a filter for renderToString I thought I might as well do one for renderToStaticMarkup – not sure there is much call for it since it is redundant with finch’s own templating system, but it’s there if anyone wants it!