Initially I went against creating a separate rehydrate function, because we decided to not actually do rehydration, but instead just regenerate the styles, because it is fast enough and more robust.
So if I did `jss.rehydrate('.style-selector')´ it would be basically inserting the styles after this element and just removing the old style node.
Now as some people had issues with mismatching selectors from SSR, it makes sense to add some more logic to rehydrate, which will make sure in dev mode that user gets proper error report.
Check that client and server setup uses the same NODE_ENV
Check the module id matches between ssr and client (first part - module id)
Check the JSS versions matching between ssr and client
if hot reload is used and modules are reevaluated, a mismatch is possible
Check the JSS instances counter matches between ssr and client. (second part - Jss instance id)
All checks could be done for e.g. if ssr generates a comment string which contains the information (dev mode only). Rehydration call checks the comment and prints a warning or error.
Initially I went against creating a separate rehydrate function, because we decided to not actually do rehydration, but instead just regenerate the styles, because it is fast enough and more robust.
So if I did `jss.rehydrate('.style-selector')´ it would be basically inserting the styles after this element and just removing the old style node.
Now as some people had issues with mismatching selectors from SSR, it makes sense to add some more logic to rehydrate, which will make sure in dev mode that user gets proper error report.
All checks could be done for e.g. if ssr generates a comment string which contains the information (dev mode only). Rehydration call checks the comment and prints a warning or error.