SSR refresh/reload during development

[msurdi]

Hi,

I've followed the setup instructions for enabling SSR, and so far everything works fine. But I've noticed that once I do any change in my frontend code, I need to stop the SSR process, rebuild it, and start it again. Otherwise the SSR'd content will be always out of date (with whatever I had in my frontend code at the time I ran the build command).

Is this intended/expected behavior? Or do you think I have something wrong with my setup?

So far I've worked around this problem by automating the rebuild and restart with nodemon, but not sure if there's a better or recommended way to handle this.

Thanks!

[craigrileyuk]

This is expected behaviour.

You should generally only be running SSR in your production environment, and you can just add the SSR build and process restart to your build/CICD process.

[msurdi]

Wouldn't this lead to discovering bugs in production which would have been discovered earlier if SSR was used during development? Imagine making use of some library that tries to access the window object or any other DOM api not available during SSR.

[craigrileyuk]

That's what SSR Testing Suites are for.

You could feasibly mount your whole app inside a test and make sure it renders to string properly.

Proper testing is going to make your life a lot easier than relying on your own eyes to spot stuff.

[msurdi]

Yes, that's better than production. But it stills makes it more difficult to debug when a problem shows up, and you have to wait for CI, etc. The earlier you detect problems the better in my opinion. That's why some of us use TypeScript for example.

Proper testing is going to make your life a lot easier than relying on your own eyes to spot stuff.

I understand your point. It's just that the world some people live in is not ideal.

[BorisTheTripper]

@craigrileyuk How would you test hydration though? You can test CSR and SSR separately no problem, but you'll never know about hydration errors until you've launched your SSR server. And the errors you'll be seeing in the browser console will give you nearly zero insight into where/how/why this hydration error occurred.

If you actually know a way to test server-to-client hydration, please share because I've been looking for a while and can't find it.

[craigrileyuk]

[msurdi]

I’m not here for a fight mate. Thanks for your help with this. Have a nice day.

[bubokko]

So what is the expected workflow here? I want to use root hydration in my app, but when the SSR is not enabled during dev, I keep getting an error about the DOM mismatch. Do people enable root hydration only on production?

[alex-uxify]

Our team stuck at the exact same location but we managed to find a workaround.

On production env the flow is like in the docs. We built a separated container which spins up the inertia server and our laravel app communicate with it.

On dev however we have 2 separate containers. The first one is running the build in watch mode with vite build --ssr --watch and the second container utilize nodemon to start bootstrap/ssr/ssr.js and watches the whole folder for file changes and restart the dev server. It's not ideal because the rebuild changes many files and this could trigger many restarts. This can be tackled with nodemon delay.

[BorisTheTripper]

@alex-uxify What is meant by "the whole folder" here?

[alex-uxify]

Sorry for the confusion the whole folder in the case is the bootstrap/ssr

[BorisTheTripper]

@alex-uxify Does this approach actually give you insight on where a given hydration error occurred? Or is it just a way to discover such errors faster, without necessarily knowing where/how/why they happen? Currently I'll just occasionally build & launch the SSR server, and then rely on browser devtools and sheer intuition to diagnose & fix hydration errors. I would imagine your approach simply speeds up this process?

[rrmesquita]

I think the greatest achievement of having SSR during dev would be improving the experience of using markup assertion in feature tests.

I know Dusk can handle this, but honestly, setting it up correctly is a pain, and I miss being able to simply $this->assertSee('some text in the screen').

[vedmant]

This is pretty bad, only this inability to develop with SSR can create tons of problems, I use Nuxt apps mostly, and there are tons of issues arise with SSR like errors, hydrations mismatches, etc, and most of this can be seen and fixed during development. Not being able to develop with SSR can be a deal breaker and pain in the ass. And talking that this an expected behavior is not acceptable.

[mvalim]

This is a must have, I'm trying to create a plugin to increase performance of my apps, everything is configured and works, but I need to have the compiled HTML response in a middleware so I can save this response as a HTML file, there is no way to do it?

Edit: I need to be able to test this in development

[mvalim]

Reading the comments above, it seems you’re not willing to think outside the box or consider other use cases. I’ll probably have to rely on packages like Spatie Browsershot and queued jobs to do the work. It’s not ideal—I’ll need to make a request to my own website, and since the package is focused on performance, making an extra request when I could just get the SSR response directly feels silly—but at least I can make the package work without having to wait and see if you guys would consider this.