-
Notifications
You must be signed in to change notification settings - Fork 86
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
CSS Not in Initial Document for Prod Builds (Waterfalls) #79
Comments
Should be fixed in v0.0.63 (#80) |
I am still experiencing this in 0.1.1 |
After more research this seems to be a behavior of vite and not a bug. I have found a workaround. No worries! |
Would you like to put some details about the issue and workaround for people coming here later. |
The desired behavior is to use CSS Modules and have no visible style changes once the page loads (this is caused by CSS files being loaded in and parsed after the browser has already painted the screen) The issue begins with how vite behaves differently between its dev server and its build output When building, vite takes your styles and separates them into CSS files that get loaded at different times depending on when they are needed. In the case of SolidStart and vinxi, these CSS files are loaded in as part of "modulepreload" functionality. This is intended to have your assets loaded in the background upon an action (such as hovering an anchor tag) so that the page transition happens faster. The modulepreload functionality is nice during page transition, but awkward during initial load of the page. These CSS files for the page you are loading are fetched by JavaScript, not by link tags in your document's head, so the browser does not wait for them before painting the screen, so when they arrive its too late and you see style changes. This is not an issue when cssCodeSplit is set to false (it makes just 1 CSS file with ALL styles thats loaded with the initial document) but there are bugs I ran into with this vitejs/vite#1141 (comment) It is also not an issue with Tailwind because this also just puts all utility classes into 1 CSS file loaded with the initial document. So what is the workaround for CSS Modules? On initial page load, I check which route path I am entering and inline the CSS Module styles into the document: import styles_home from '#/routes/pages/home/(home).module.css?inline'
import styles_upload from '#/routes/pages/upload/(upload).module.css?inline'
export default createHandler((context) => (
<StartServer
document={(props) => {
return (
<html lang='en'>
<head>
<meta charset='utf-8' />
<meta name='viewport' content='width=device-width, initial-scale=1' />
<style>{context.path === '/' ? styles_home : styles_upload}</style>
{props.assets}
</head>
<body>
<div id='app'>{props.children}</div>
{props.scripts}
</body>
</html>
)
}}
/>
)) This will immediately apply the necessary styles, while also still loading (and caching) the separate CSS file, so no change in styles can be seen. This solution may imply that all route paths can only have 1 CSS file, for having more CSS files further down in the route paths may result in the same issue (and needing to inline more styles with more route logic) but this works for my use case. |
We are still experiencing the same problem Are there any news or thoughts how to overcome the problem? Checking paths manually and inline needed CSS is not an option unfortunately, because it's a very fragile solution and will create additional complexity |
It is indeed fragile. I abandoned it in favor of Tailwind. When using CSS Modules with any SSR framework, you will run into issues or inefficiencies by the nature of SSR and CSS code splitting. When loading modules at runtime, you cannot predict which ones will be loaded in what order, and therefore which CSS files will be loaded in what order. You may end up fetching CSS files that were already fetched if 2 JS modules both depend on it, and this is not even to mention issues with CSS style ordering complications. You can find many GitHub issue threads, and forums about this, I haven't researched it in a long time though. |
@sabercoy btw we tried css-in-js using emotion with start framework, worked like magic (works out of the box since 10 version) |
@nikolayemrikh yes, you avoid the pitfalls because your JS comes with CSS baked in this even suggests doing that: gregberge/loadable-components#94 (comment) though im not a fan of CSS-in-JS, but thats a different topic lol |
In dev mode, the initial document will render with CSS embedded
When running a production build, CSS Modules are split out and fetched after initial document load (causing waterfall)
I noticed this initially using CSS Modules (turning the "HELLO WORLD!" red with a class, and now see this can also be observed with the basic template of solid-start (no CSS Modules)
The text was updated successfully, but these errors were encountered: