-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
feat: container APIs #11051
feat: container APIs #11051
Conversation
🦋 Changeset detectedLatest commit: 239a41c The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
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.
This PR is blocked because it contains a minor
changeset. A reviewer will merge this at the next release if approved.
!preview container |
Snapshots have been released for the following packages:
Publish Log
Build Log
|
* | ||
* | ||
* @param {AstroComponentFactory} component The instance of the component. | ||
* @param {ContainerRenderOptions=} options Possible options to pass when rendering the component. |
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.
What's this =
at the end of the type? Saw it in a few places
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.
With TSDoc, we should also be able to remove the type altogether so we don't have to declare it in two places.
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.
@Princesseuh It's a JSDoc thing to mark a @param
as optional
48e2cfd
to
ed9a2be
Compare
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 think I mostly only need to look at the changeset in this PR, but here are some suggestions re: what I was thinking, to give you an idea!
See what you think, and edit/take from it whatever you like!
"test": "vitest run" | ||
}, | ||
"dependencies": { | ||
"astro": "experimental--container", |
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.
Just want to check on this. Will this be the "version" of Astro to use for this starter when 4.9 is out? But, it's not an experimental flag people have to enable in config?
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.
This is required for the time being, otherwise astro check
will fail, which is run in our CI. We will change this straight after we will release v4.9
*/ | ||
params?: Record<string, string | undefined>; | ||
/** | ||
* Useful if your component needs to access some locals without the use a middleware. |
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.
Just a quick note here that I did some editing of descriptions for these in the Container API page PR for docs. These could always be revisited after that is finalized, and/or these could have links to docs (not sure what the proper/usual M.O. is here with these code comments as I don't usually edit them).
But, I have made some suggestions in the docs PR itself for these!
Co-authored-by: Sarah Rainsberger <[email protected]>
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.
Changeset looks good to me, so if everyone is happy with its content, consider it approved by docs!
|
||
componentMetadata(_routeData: RouteData): Promise<SSRResult['componentMetadata']> | void {} | ||
|
||
headElements(routeData: RouteData): Promise<HeadElements> | HeadElements { |
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.
What is this function used for?
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.
Ok, I see now that this is called when the render context is created.
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 used some code we already use in dev/build/ssr. We will probably need to review it in case it causes bugs.
Changes
Relative RFC: withastro/roadmap#916 (this RFC will be soon updated based on the APIs and options crafted in this PR)
As for now, we publicly expose the following methods:
create
: creates a new instance of the containerrenderToString
: renders a component to stringrenderToResponse
: returns the response emitted by the rendering phaseThe methods
insertRoute
andcreateFromManifest
were left private using TS on purpose because I still want them available so I can still play with them without breaking the compatibility with end users.The goal is to provide, for now, the ability to test components with
vitest
. This would allow us to quickly release the APIs and receive feedback.Testing
Added unit tests and example tests
Docs
withastro/docs#8281
/cc @withastro/maintainers-docs for feedback!