You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A problem I'm facing at work: we're using SvelteKit (or rather will be, soon) as an SSG to render several thousand pages. We also need to create AMP versions. Much as I would like to tell AMP to fuck right off, its existence is an unfortunate reality that affects many potential SvelteKit users.
This has at least a couple of consequences (and possibly more):
Specifying a template file
The two versions of the app need different templates. One idea that doesn't feel too much like scenario-solving: instead of src/app.html being hardcoded, it could be an option passed via the CLI or svelte.config.js that defaults to src/app.html:
You can't have scripts or external stylesheets in an AMP document. Right now, %svelte.head% includes <link rel="stylesheet"> elements for all the critical CSS files in production, the CSS itself in a <style> tag in development, and the <script> that calls start(...) in both. We can't just omit the %svelte.head% because then there wouldn't be any styles.
Meanwhile %svelte.body% contains the <script> that populates the global __SVELTE__ variable (which we could arguably get rid of, if we included its contents in the options passed to start(...), though that's a separate conversation).
One possible option would be to split %svelte.head% and %svelte.body% into different pieces that you could chop and change as you saw fit...
<body>
%svelte.body.markup%
<!-- only include this on the non-AMP template -->
%svelte.body.script%
</body>
...but that still doesn't help us with the fact that styles need to be inlined inside <style amp-custom>. Nor would a --no-hydrate CLI flag or equivalent. So I'm reluctantly concluding that we probably need dedicated AMP support that deals with this nonsense for you. We wouldn't be alone — Next apparently concludedthe same.
Then again, maybe this could live in an adapter (or the existing adapter-static)... somehow? AMP pages are static by their very nature, though you do need to provide dynamic endpoints for things like amp-access.
I'll probably open a PR for the custom template thing, since that seems like the less controversial part, and since my immediate needs as far as the other thing goes could probably be met in userland, albeit hackily.
The text was updated successfully, but these errors were encountered:
A problem I'm facing at work: we're using SvelteKit (or rather will be, soon) as an SSG to render several thousand pages. We also need to create AMP versions. Much as I would like to tell AMP to fuck right off, its existence is an unfortunate reality that affects many potential SvelteKit users.
This has at least a couple of consequences (and possibly more):
Specifying a template file
src/app.html
being hardcoded, it could be an option passed via the CLI orsvelte.config.js
that defaults tosrc/app.html
:or
Disabling hydration and excluding stylesheets
You can't have scripts or external stylesheets in an AMP document. Right now,
%svelte.head%
includes<link rel="stylesheet">
elements for all the critical CSS files in production, the CSS itself in a<style>
tag in development, and the<script>
that callsstart(...)
in both. We can't just omit the%svelte.head%
because then there wouldn't be any styles.Meanwhile
%svelte.body%
contains the<script>
that populates the global__SVELTE__
variable (which we could arguably get rid of, if we included its contents in the options passed tostart(...)
, though that's a separate conversation).One possible option would be to split
%svelte.head%
and%svelte.body%
into different pieces that you could chop and change as you saw fit......but that still doesn't help us with the fact that styles need to be inlined inside
<style amp-custom>
. Nor would a--no-hydrate
CLI flag or equivalent. So I'm reluctantly concluding that we probably need dedicated AMP support that deals with this nonsense for you. We wouldn't be alone — Next apparently concluded the same.Then again, maybe this could live in an adapter (or the existing
adapter-static
)... somehow? AMP pages are static by their very nature, though you do need to provide dynamic endpoints for things like amp-access.I'll probably open a PR for the custom template thing, since that seems like the less controversial part, and since my immediate needs as far as the other thing goes could probably be met in userland, albeit hackily.
The text was updated successfully, but these errors were encountered: