Replies: 6 comments 15 replies
-
You may be able to use a middleware and html-parse the entire response and remove scripts that way. You would lose the benefit of streaming, but since you are concerned with static sites, it's acceptable to buffer the entire response body. |
Beta Was this translation helpful? Give feedback.
-
Thanks for bringing this up! I think there's something possible here, but with some caveats.
|
Beta Was this translation helpful? Give feedback.
-
Adding some related observations to this. I'm not sure if this is the same cause, but I'm seeing this even for files included with
That was surprising. I tried to use |
Beta Was this translation helpful? Give feedback.
-
I think a neat solution is possible here. ---
import Comp1 from './Comp1.astro'
import CompN from './CompN.astro'
import * as Namespace from 'library'
const map: Record<string, Component> = {
comp1: Comp1,
compN: CompN,
}
const Comp = pickOne(map)
const Heading = random ? "h1" : "h2"
$$propagate($$result, Comp, Heading, Namespace.Group, Namespace.GroupItem)
---
<Heading/>
<Comp/>
<Namespace.Group>
<Namespace.GroupItem/>
</Namespace.Group>
It would need help from both the compiler and the rendering runtime, but Vite does not need to be involved, and it includes the scripts only once per page inside the I came up with the idea thinking of a way to combine statically added assets and propagated assets (content collections). Unfortunately, the idea doesn't quite achive that. We can wait for the |
Beta Was this translation helpful? Give feedback.
-
Implemented as an integration |
Beta Was this translation helpful? Give feedback.
-
👋 This might have come up before, but I'll give it a shot: <astro-island>
<link rel="styleeshet" href="Component.bundle.hash.css" blocking="rendering" fetchpriority="low">
<div>...Rest of the component html</div>
</astro-island> With response streaming, I think this could work pretty well. It seems you can mitigate FOUC in various browsers (like FF), ref Jake Archibalds blogpost from some years ago: https://jakearchibald.com/2016/link-in-body/ Ref There might be some performance penalities in some cases, but at least it might be up to the developer to "fine grain" this for each project 😊 WDYT? |
Beta Was this translation helpful? Give feedback.
-
Body
Summary
Stop including
<script>
tags in a page build when a component is not printed in the page.Background
This is coming from withastro/astro#8223 at the demand of @bluwy ; I personally believe this is a bug, but as I understood from my issue it's rather a known caveat which i would like to discuss removing.
TL;DR
I simply believe that this should not be a reality:
Child.astro
src/pages/index.astro
Coming from Next/Nuxt, this feels not natural and I believe most would file this as a bug.
Motivation
The motivation is to solve a problem I'm having which comes from a pretty common usecase.
I'm building a static website from a 3rd party CMS (in my case Strapi) for which page structure is dynamic.
When dealing with such as structure, you must have a
getComponentByType()
method which helps to compute the content of the page. When doing so, at some point you load component based on theirtype: string
definition. There are 2 options:Dynamically
We build a map of "block type to import path" and load the components on demand.
When doing so, it cuts a few features. Notably, the
<script>
tag of the component loaded cannot be bundled and is not added to the page (because of the dynamic loading)Statically
We can build a map of "block type to component" and simply return the component.
When doing so, since every component is statically listed, every component of the map is included in the bundling of the page even when they are actually not used in the page.
This is very unusual compared to any other component libraries/framework out there, even tho i'm very aware of the unique angle of Astro.
Goals
<script>
tags used in a page, we should move away from static analysis to runtime analysis.Beta Was this translation helpful? Give feedback.
All reactions