When the SSR feature is enabled in development, the watcher process correctly monitors and rebuilds the SSR module during development, so that any change you do to the frontend Pages or Components, etc is correctly rebuilt and available for being served from the server.
Problem
I've found that the current way the SSR is done prevents newly built versions from being picked up after the first SSR operation is performed.
This means that when reloading the application in the browser, either by CMD+R or by the live reload system from Adonis.js itself a small "flicker" will happen, because the browser will have received outdated HTML markup from the server and then it will have been replaced by the CSR rendering on the browser.
If React's hydrateRoot is used instead of createRoot (as in the example linked below) then an error is echoed in the browser's console explaining that the CSR generated DOM doesn't match the SSR generated DOM.
One way to avoid this is to restart the Adonis.js main server/development process so that it picks up the freshly rebuilt version of it, but it's annoying to do after every frontend code change.
Proposed solution
This Pull Request adds a new SSR setting for this project, named autoreload that, when enabled (usually just in development), will then take care of removing from Node.js' require cache the already loaded module, so that every time the SSR content is generated it will be done using the latest built frontend code. This happens here.
I'm not sure if I was having this problem because I did some wrong setup, missed some docs, etc. Feel free to close this issue if I got it wrong on the first place
I was on the fence between adding a setting (as I did) or just check if the application is running in development via NODE_ENV, etc and avoid the configuration burden for the end user by adding another setting.
I'm not even sure autoreload is descriptive enough for this setting. Any better suggestion?
I've had to tweak a bit the SSR test utils helper function's return value. Not sure if this is the best approach. I'm happy to change it if you have a better suggestion.
This probably has some performance impact (which I've not noticed nor measured) but I don't think it would be a big problem because this would be used only during development.
Thanks for your work on this project, and hope you find this interesting or useful enough to get it merged in.
Context
When the SSR feature is enabled in development, the watcher process correctly monitors and rebuilds the SSR module during development, so that any change you do to the frontend
Pages
orComponents
, etc is correctly rebuilt and available for being served from the server.Problem
I've found that the current way the SSR is done prevents newly built versions from being picked up after the first SSR operation is performed.
This means that when reloading the application in the browser, either by
CMD+R
or by the live reload system from Adonis.js itself a small "flicker" will happen, because the browser will have received outdated HTML markup from the server and then it will have been replaced by the CSR rendering on the browser.If React's
hydrateRoot
is used instead ofcreateRoot
(as in the example linked below) then an error is echoed in the browser's console explaining that the CSR generated DOM doesn't match the SSR generated DOM.One way to avoid this is to restart the Adonis.js main server/development process so that it picks up the freshly rebuilt version of it, but it's annoying to do after every frontend code change.
Proposed solution
This Pull Request adds a new SSR setting for this project, named
autoreload
that, when enabled (usually just in development), will then take care of removing from Node.js' require cache the already loaded module, so that every time the SSR content is generated it will be done using the latest built frontend code. This happens here.I've also included some tests for this feature, and I've created this minimal example project demonstrating the issue I was having.
Questions, ideas, etc
NODE_ENV
, etc and avoid the configuration burden for the end user by adding another setting.autoreload
is descriptive enough for this setting. Any better suggestion?Thanks for your work on this project, and hope you find this interesting or useful enough to get it merged in.