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]

So you use Typescript to catch problems early but using a testing suite as part of your development flow is too much because "the world is not ideal"?

You can run Vitest or other testing whenever you like during development. Why would you have to wait for the CICD pipeline to do so?

The SSR build is, by design, one single, self-contained package containing fully-compiled assets. You can stick a reload watcher on it (as you do already), but there's no possibility of extending HMR to work with it.

Therefore, proper testing is your best (and easiest) bet.

[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').