-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Add config option to serve all stylesheets in all pages (for SPA-like apps) #10894
base: main
Are you sure you want to change the base?
Conversation
|
What about disabling vite.build.cssCodeSplit? I think it should also work in Astro. |
@bluwy That does work! but only for builds, it does not seem to work with the I was able to get it working for builds previously as an integration (calling the same I could modify the PR to remove the custom post-build functionality, instead setting the Vite build config based on the new config setting. Also, might be a good idea to rename from i.e. if |
I've modified the PR as per my comments above. Alternatively, instead of introducing a new astro setting, it could simply read the vite one. But I think a new astro setting makes sense as it will affect the astro dev server and not just the vite build process, and it can also have astro-specific docs. |
Thanks for trying that out. I'd recommend that we discuss a bit more about the feature first before making more commits, at the risk that this might not be accepted 😅 For me, I don't quite understand why we also need to merge them in dev. Currently the crawl is only meant to prevent FOUC in dev. The links/styles need to be in a specific format in the HTML for Vite to not double-inject the links/styles. I think the issue described in your proposal could be resolved with a different way? It's similar to the View Transition router we have now, where when we navigate to a new page, we fetch the new HTML and load the styles in the current page. Which gives an SPA-like experience too. Could enabling View Transitions in your app also help with this? |
@bluwy thanks for the suggestion.
If they are not merged in dev, then when I run I think it is overkill to have to enable a client-side library (View Transition) just to get this to work in the I understand this might not get merged but I do believe it is a legitimate use case for HTMX users that don't want to deal with global CSS styles and managing them manually. I will prepare a template / minimum reproducible example to showcase this later and I'll link it here. If there is an existing option in Astro to achieve this in both dev and build by simply toggling some setting, that would be great and exactly what I'm looking for. But I'd rather not add user code like View Transitions if it is not strictly necessary. |
I'm not familiar with HTMX, but about:
If it's loading the entire page, shouldn't it also inject the related style/links from the other page, into the current page? Usually scripts that makes MPA feel like SPAs would handle this too. I think this issue can be solved externally, and without needing to change Astro. |
@bluwy I worded myself poorly regarding HTMX. HTMX does not load or redirect to a new page, it actually fetches some HTML snippet from the server and replaces that without ever leaving the page. With this functionality, parts of the page can be swapped similarly to how a client-side router would behave, except there is no virtual DOM as all of the data comes from the server as HTML. But HTMX only fetches HTML, it does not fetch any CSS etc. So this requires all of the CSS to be pre-loaded in the initial page load, which is something that the Astro dev server would have to allow, otherwise it only works when previewing a production build -- hence my PR / fork to get this to work for my use case. To reiterate, this is really just about convenience -- allowing HTMX developers to use SCSS modules and preview their app correctly in the Astro server. If there is any alternative to this that doesn't require adding extra client scripts, I am open to suggestions :) |
I made a minimal reproducible example for facilitating the discussion: https://github.com/rellfy/astro-htmx-css-mre |
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.
Blocking for now, because we usually are a bit conservative about adding new features without a discussion and an RFC.
Also, the PR doesn't have a changeset.
Changes
For context, see withastro/roadmap#909
Testing
This feature was only tested manually.
Docs
Comments were added to the new config option.