-
Notifications
You must be signed in to change notification settings - Fork 320
vite
: Add inlineCssInDev
option to fix FOUC in SSR dev
#1614
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 8190398 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Much needed to improve the SSR load dev experience.
Best reviewed with hidden whitespace.
During development, Vite SSR/SSG applications typically call
ssrLoadModule
to load some sort ofrender
entrypoint that's used to generate some initial HTML. The Vite plugin handles compilation of VE styles duringssrLoadModule
, so all classnames are present in the DOM, but the CSS generated by VE is not.Until Vite gains first-class support for injecting CSS during SSR, it looks like the common solution is to inject it yourself vitejs/vite#2282. By iterating of the
cssCache
in the compiler, we can get all CSS generated duringssrLoadModule
, and inject it into thehead
.Consumers could further optimize their dev critical CSS if they want to with something like
beasties
.In my eyes this replaces
unstable_mode: 'transform'
, at least during development.transform
also suffered from falling back to the old compilation method, where asinlineCssInDev
at least uses thevite-node
compiler.Tests
While I wanted to add an SSR fixture to the repo, in its current state I think this would involve a decent refactor/some hacks to get working. I've tested this in
sku
and am happy with the behaviour, so I'm ok with not having test coverage for the time being.