-
Notifications
You must be signed in to change notification settings - Fork 32
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
Prerender API #362
Prerender API #362
Conversation
I'm wondering how this will work for dynamic routes like |
proposals/0000-hybrid-output.md
Outdated
|
||
```astro | ||
--- | ||
export const output = 'server' |
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.
will it be possible for our language tools to give type checking and auto-complete as an export const
?
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.
Probably possible! Can add a note about this.
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.
Confirming that it's possible! We'll have to either provide a type for it, or fake completions / diagnostics (like NextJS does)
proposals/0000-hybrid-output.md
Outdated
- Having a separate mode for `hybrid` increases cognitive overhead and the learning curve of Astro. | ||
- `hybrid` output should arguably be the default `output` mode (similar to Next.js), but to avoid a breaking change we're going with an opt-in adoption approach | ||
|
||
# Alternatives |
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.
Might be nice to add cache headers as an alternative here, even if just to show how many hoops have to be jumped through to properly handle caching in a CDN via headers, it's not the easiest balancing act 😅
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.
I completely agree that Astro should just always be hybrid!
In astro.config
the output
option could be renamed to defaultOutput
to set the default for the hybrid mode. The default mode can be overridden by exporting the output
from the frontmatter. 🤔
This would be the most flexible approach imho and also would be super logical and not change the learning curve.
- I am totally unclear how the output would look like and how we would handle adapters as we always need an ssr-adapter to do anything on the server. E.g. we would always export a directory with client and server folders, which is weird if there is no ssr happening.
- I understand that this would mean a breaking change, but still worth a though.
Maybe we should keep in mind to allow the syntax to support other future modes (other than I have seen some interest (myself included) in ISR. This is currently mostly solved with cache headers, which can be painful IMHO. ISR would require an option to set the rebuild cycle. This would not really be compatible with the current proposal. One way with the current proposal would be to encode the cycle in the string. This would require parsing and make the typing more complex. It does not seem clean at all. ---
export const output = 'isr-1000' // `isr-{cycleInMs}`
--- Or we could add the cycle as an option to add per file. Which would add another option only for ISR. ---
export const output = 'isr'
Astro.response.isrCycle = 1000
--- |
As from the call, I think we have multiple concepts we are grouping under
Then there's this other thing called imo, when you specify So in my mind we have two concepts, one is a signal to Astro and one is a signal to adapters. We could call this other thing |
output
This would mean, that there is no such thing as a hybrid output, right? We can set the output to static to produce a static HTML site and to server to produce something to be run on a server which might include some static files.
Not really sure here. Would we serve the static content ourselves, or would the adapter take care of serving the static files? adapter configuration
This is currently handled by passing arguments to the adapter ASAIK. With the vercel adapter by importing the correct one: import vercel from '@astrojs/vercel/edge';
import vercel from '@astrojs/vercel/serverless'; It could also be handled by passing arguments to the adapter when registering it. |
Hi all, I just wanted to share with you, that my recent learning was that having SSR and SSG pages split by folders might also be an idea worth thinking about (instead of having them split per route with a new mode). To me, it feels quite nice from the DX point of view. I spiked this in a different way tho... with the current version 1.6.2, having different projects combined in one deployment; of course: Different projects aren't optimal and I had to come up with some solutions behind the scenes to get it working smoothly, but it does...; My learning was that it feels quite clear, intuitive and nice to have SSR and SSG clearly split "at first sight". It also helps to understand separating the concerns and could lead to less boilerplate when the developer doesn't need to specify the type of execution per route: (this screenshot is showing a split at project level which isn't optimal; but maybe a folder naming convention under "pages", like "ssr" subfolder or "ssg"/"static" subfolder could be?) If you wanna play with this: Here is the impl: https://github.com/kyr0/turbo-hybrid-astro-on-vercel#welcome-to-turbo-hybrid-astro-on-vercel I also explained my spike results/learnings here: |
Thanks for all the feedback, everyone! I am going to update this RFC to take all of it into account and we'll be chatting about this again in a more focused RFC-specific call this week. For a quick summary of the expected changes:
|
Changes from `output: hybrid` to `output: server` + `export const output = "static"`
@natemoo-re one question I hadn't thought about until this morning, how will this work for integrations or components that either work differently in Two examples that came to mind for me:
|
@tony-sull Hopefully this is outlined better in the updated RFC, but since this mode is now being treated the same as |
@tony-sull image will be an interesting one to think through, but I think |
I really am a huge fan of this proposal and think that either Alternative option F or @kyr0's proposal would be the options that I favor the most for this feature. I have no idea how complicated the implementation internally would be for either of these, but I particularly like the idea of alternative F that allows you to name a file with a Alternative C I think is also a decent option because then you're only ever using 1 specific named value in the Astro template, and you can extend that object with as many per-page options down the line with no breaking changes required. Feels like a better version of the current proposal with none of the future potential downsides. Next.js 13 beta recently added quite a few new named variable exports in their files for configuring caching that I just am not a fan of, as I think that for beginners it's gonna be really hard to discover that those values mean something specific. It's nice if you know how it works because it's terse and quick to write, but I think it just is really hard to google/search for answers to if you're a beginner. If there's gonna be a named export that means something, I usually think using an object or function (like Looking forward to see how this RFC develops! |
Summary
pages/
at build time.export const prerender = true
in any file in thepages/
directory that should be prerenderedLinks