Closed buhrmi closed 2 years ago
Hey @buhrmi thanks for the PR. The reason Inertia doesn't render the template is because it's returning the already rendered HTML response from the internal node server. The process basically goes like this when SSR is enabled:
Because we're returning the full html and javascript isn't involved, there's no hydration process on the initial load of an SSR page. If the user has javascript enabled, regular inertia requests will take over afterwards.
Let me know if my explanation doesn't make sense!
If the user has javascript enabled, regular inertia requests will take over afterwards.
How? How can inertia take over, if the template isn't rendered and the <div id="app" data-page="...">
doesn't exist in the HTML that is sent to the browser on first load? Where would inertia mount the app?
I just ran a Vite/React SSR build locally and the app div with the data-page is rendered on the page with all of the SSR rendered html within it.
Here's the rendered HTML from my inertia template repo inertia-rails-template.txt
Yeah, I just looked at the source of https://pingcrm-vite.herokuapp.com/login (from @ElMassimo ). It also includes the <div data-server-rendered="true" id="app" data-page=...
. I can't figure out where it comes from because I can't find the string "server-rendered" anywhere in the inertia-rails repo 🤔🤔
Okay, after digging a little bit deeper, it looks like the client-side adapters are responsible for rendering the intial <div id="app">
element. Will close this PR.
Currently, the Rails adapter throws away the initial page data in the server-side rendered HTML. This makes it impossible for the client to "take over" and hydrate the page. This PR keeps the initial data and also adds a
data-server-rendered="true"
attribute to it, bringing it in line with the other adatpers.