Add config option to serve all stylesheets in all pages (for SPA-like apps)

[rellfy]

Changes

For context, see withastro/roadmap#909

Testing

This feature was only tested manually.

Docs

Comments were added to the new config option.

[changeset-bot]

⚠️ No Changeset found

Latest commit: be39049

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[bluwy]

What about disabling vite.build.cssCodeSplit? I think it should also work in Astro.

[rellfy]

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 astro dev server.

I was able to get it working for builds previously as an integration (calling the same mergeSpaStylesheets function in this PR), but it's great that a Vite setting can be set to handle this instead. I definitely missed that from the docs.

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 build.mergeSpaStylesheets to build.cssCodeSplit so that it matches Vite's, but also applies to the local dev server.

i.e. if build.cssCodeSplit is set to true, then vite.build.cssCodeSplit would also be set to true during builds and it also works with the dev server.

[rellfy]

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.

[bluwy]

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?

[rellfy]

@bluwy thanks for the suggestion.

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.

If they are not merged in dev, then when I run astro dev in my Astro/HTMX app, and have a HTMX component load a different page for me (without reloading the entire page in the browser) that page will not be styled at all. So for me to test the correct behaviour I would have to run astro build && astro preview instead, which is disappointing.

I think it is overkill to have to enable a client-side library (View Transition) just to get this to work in the astro dev server. With this PR I can simply enable an option and get this use case to work in both the dev server and for production builds.

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.

[bluwy]

I'm not familiar with HTMX, but about:

have a HTMX component load a different page for me (without reloading the entire page in the browser) that page will not be styled at all

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.

[rellfy]

@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 :)

[rellfy]

I made a minimal reproducible example for facilitating the discussion: https://github.com/rellfy/astro-htmx-css-mre

[ematipico]

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.