Zaid-Ajaj
commented
4 years ago Let me try to break this down.
First of all, what is server-side rendering from the point view of the library? It is having the ability to render Html from the server directly on the initial render only and give that Html to React to hydrate it's internal virtual-dom with it. In other words, creating the virtual-dom of your application from Html that was rendered on the server and served to the client. This allows web crawlers to process that Html returned from the server before your client-side javascript needs to execute.
So this SSR matter is really about being able to run Feliz from the server/backend:
// Server-side code
let initialState, unusedCommand = Shared.init()
let dispatch msg = ignore()
let userInterface : ReactElement = Shared.render initialState dispatch
let staticHtml : string = ReactDOM.renderToStaticMarkup userInterface Already supported on node.js
Does Feliz supports running this code for SSR? Yes it already does but only when you run code from a node.js server, not a dotnet one. This means you can use Feliz right now to build static websites and whatnot using modern tools like Gatsby or Next.js because they run a node.js server.
How is then Fable.React able to run on a dotnet server? That is because that library uses compiler directives such that when it is compiled using dotnet, it will render Html using dotnet APIs instead of the Fable/React ones. It is the same public API but it executes different code depending on whether or not it is compiled using Fable or dotnet.
This means the issue really is how to make Feliz run on a dotnet server to support SSR from dotnet? Do we delegate component creation to Fable.React and piggyback on that existing functionality? I don't believe that is a good solution because I want to get rid of the Fable.React dependency eventually (right now, it is only there for compatibility reasons)
Do we do something similar to Fable.React? Well, if you look at the internal code, it is one big mess with all the compiler directives all over the place. I am absolutely against that and would rather develop the library as a pure React binding without considering the limitations of some React API that wouldn't "translate nicely" using dotnet APIs.
Enter Feliz.Server
I propose a solution to this problem that wouldn't stand in the way of Feliz and still be quite nice to use from dotnet: Build a separate library called Feliz.Server with the same public API as Feliz when it comes to the Html/style/prop API and React components/hooks that internally uses dotnet to generate the Html.
From a consumer point of view, you write this code in dotnet:
#if FABLE_COMPILER
open Feliz
#else
open Feliz.Server
#endif
let initialState, unusedCommand = Shared.init()
let dispatch msg = ignore()
let userInterface : ReactElement = Shared.render initialState dispatch
let staticHtml : string = ReactDOM.renderToStaticMarkup userInterface In the snippet above, the functions Shared.render Shared.init are shared between client and server.
When will Feliz.Server be available?
When someone steps up and build it. It is definitely on the road map but not a priority and I could do it myself, but I am afraid not any time soon because I have many projects in progress (for example Feliz.AntDesign, check it out) and would rather focus on Feliz itself and growing it's ecosystem.
No SSR =/= No Searchability
As I understand it, SSR is a must to get any kind of SEO/searchability.
AFAIK modern web crawlers/indexers will gladly wait for the content to show up on your website even if it is not available on initial render (and needs to be rendered after data is retrieved). Google's Googlebot uses a headless browser to look at the content of the page and go through the links included in it, read https://vuejsdevelopers.com/2018/04/09/single-page-app-seo/
cmeeren
mvsmal
mastoj
MangelMaxime
dbrattli
Shmew
bengobeil
I love almost everything about Feliz, but the lack of SSR causes me some concern.
In short, I'd like to experiment with Feliz for creating websites. As I understand it, SSR is a must to get any kind of SEO/searchability.
Other than that I know next to nothing about SSR, though. (Including how easy/hard it would be to create a website using SSR.)
What would be needed to support SSR? Is it a large undertaking? Could it be considered, or is this an instant-close wontfix?
For the record, SSR support has been touched on previously in #31 and #49. But #31 did not center on SSR, and #49 was closed after I simply quoted a comment from #31. So I thought I'd make an "official SSR issue" for "official" consideration.