-
-
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(next): astro:routes:resolved #12329
base: next
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 5576af9 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 |
@@ -544,6 +544,7 @@ export class experimental_AstroContainer { | |||
type, | |||
fallbackRoutes: [], | |||
isIndex: false, | |||
origin: 'user', |
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'm not sure what we should use here
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.
@@ -15,6 +15,7 @@ export const DEFAULT_404_ROUTE: RouteData = { | |||
route: '/404', | |||
fallbackRoutes: [], | |||
isIndex: false, | |||
origin: 'core', |
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.
Although we use "core" to refer to the astro
package, is this as clear to users of the API as it is to us? Maybe origin: 'astro'
would be better for users.
/** | ||
* Dynamic and spread route params | ||
* ex. "/pages/[lang]/[...slug].astro" will output the params ['lang', '...slug'] | ||
*/ | ||
params: RouteData['params']; |
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'll miss the generate
function from IntegrationRouteData
to generate URLs for a given route. Integrations will have to construct their own URL generator function based on the pattern
and params
which seems somewhat unnecessary since that function already exists in Astro and just isn't exposed.
It is not a blocker since it can be done in user-land
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've included the minimum properties, but it's the opportunity to rethink this api tbh! So feel free to suggest things and we'll talk about it at the standup
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 it makes sense to keep generate
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.
The only field used on official integrations/adapters that can't be recomputed on the consumer is type
to indicate whether the route is an endpoint, page, redirect, or fallback.
pathname
is nowpattern
, so it is just a renamesegments
can be computed frompattern
generate
can be created fromsegments
So I think at least type
should be present.
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 wonder if segments
and generate
should be properties on the object, or functions exported by Astro where you can pass pattern
/segments
@@ -225,13 +217,18 @@ export interface BaseIntegrationHooks { | |||
'astro:build:done': (options: { | |||
pages: { pathname: string }[]; | |||
dir: URL; | |||
/** @deprecated Use `routes` from `astro:routes:resolved` instead */ |
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.
If we intend to remove this, we'll need to think more about how to provide the existing functionality elsewhere. Fields not exposed on the new hook are relied upon by integrations and adapters, including official ones:
- Sitemap relies on
type
,pathname
, andgenerate
- Most adapters rely on
type
to emit redirects efficiently in their specific format - The Cloudflare adapter relies on the
segments
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.
Indeed! Hence the need to think about all the properties we should include, it doesn't need to be a 1:1
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.
distURL
shouldn't be part of the new type, however it should be provided in the hook build:done
;
Perhaps, it makes sense to evaluate a new type for the build:done
hook, and not pass certain types, such as params
, segments
, generate
.
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.
Then we can deprecate properties on build:done
routes
, instead of the whole routes
list
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.
Then we can deprecate properties on
build:done
routes
, instead of the wholeroutes
list
Yeah that sounds like a good thing
I read the previous PR, and I couldn't find anything regarding |
/** | ||
* Whether the route comes from Astro core, an integration or the user's project | ||
*/ | ||
origin: 'core' | 'integration' | 'user'; |
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.
Some alternatives:
- internal: coming from Astro
- external: coming from integrations outside Astro core
- project: coming from a user project
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.
origin
was suggested by Luiz, see withastro/roadmap#998 (comment)
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.
My suggestion was regarding the variants, not the name origin
.
core
->internal
(we don't usually use the term core when "talking" to users)integration
->external
user
->project
(users think about project, not "user". A project might belong to a team, multiple users)
/** | ||
* Source component URL | ||
*/ | ||
entrypoint: RouteData['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.
Why do we change the internal naming? Wouldn't it create fragmentation? Also, we shifted into a pattern where "entrypoint" is URL
or string
, where the string
is an absolute file path. In this case, these are string
, and they are relative paths. I think we should keep component
, so they are not misunderstood like the other "entrypoints" we have in other APIs.
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 proposed changing the "component" name for the new public API because the value here is not necessarily a component. This is already true of RouteData['component']
, the name is misleading.
I'm not sure whether entrypoint
is the best name either. It can be:
- A relative path when the route is a redirect
- The absolute path to an Astro component when the route is a page
- The import path (before resolving dependencies) of an Astro component when the route is a page
- The absolute path to a JS file when the route is an API
- The import path (before resolving dependencies) of a JS file when the route is an API
It is quite an overloaded field, so I think it needs a more generic name than "component".
Some options and my thoughts about them:
source
: would be misleading for redirect since it is where it redirects to and not fromdefinition
: I don't think it really fits with redirectimplementation
: also doesn't fit with redirecttarget
: seems weird to say an Astro component is the target of a page but could workreference
: in the sense of a "reference implementation" for the page or API and the reference link for the redirect
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 about origin
or creator
?
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.
cc @Fryuni
@@ -225,13 +217,18 @@ export interface BaseIntegrationHooks { | |||
'astro:build:done': (options: { | |||
pages: { pathname: string }[]; | |||
dir: URL; | |||
/** @deprecated Use `routes` from `astro:routes:resolved` instead */ |
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.
distURL
shouldn't be part of the new type, however it should be provided in the hook build:done
;
Perhaps, it makes sense to evaluate a new type for the build:done
hook, and not pass certain types, such as params
, segments
, generate
.
/** | ||
* Dynamic and spread route params | ||
* ex. "/pages/[lang]/[...slug].astro" will output the params ['lang', '...slug'] | ||
*/ | ||
params: RouteData['params']; |
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 it makes sense to keep generate
Co-authored-by: Luiz Ferraz <[email protected]>
*/ | ||
redirectRoute?: IntegrationRouteData; | ||
}; | ||
|
||
export interface IntegrationResolvedRoute |
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.
The discussion was marked as resolved because of commits, but we need to figure out the renaming of some fields
); | ||
await new Promise((r) => setTimeout(r, 100)); | ||
|
||
assert.deepEqual( |
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 failing but I can't figure out why. Looks like the partial update of the manifest is not working as expected
Changes
astro:routes:resolved
hook, that runs beforeastro:config:done
and on any route change on devIntegrationRouteData
to integrations #11864, we talked about bigger refactorings but left the shape similar for backward compatibility. With this PR, we can do whatever we want with the shape!Testing
Adds a test for dev
Docs
Will write docs after the PR is approved