-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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(core): add routePattern
to GetStaticPathsOptions
#13520
base: main
Are you sure you want to change the base?
feat(core): add routePattern
to GetStaticPathsOptions
#13520
Conversation
🦋 Changeset detectedLatest commit: 20c8125 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 |
CodSpeed Performance ReportMerging #13520 will not alter performanceComparing Summary
|
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.
Blocking because this isn't a patch, but a feature
routePattern
to GetStaticPathsOptions
Thank you @openscript for the PR. It's not very clear what this new feature is for. I read the description, but unfortunately, it doesn't provide a good enough example of how users should consume the new parameter. As for the tests, there's a contribution guide that should help. As for where, you could create a new file or extend the existing one. You will have to create new fixtures or files where you use the new feature, and execute certain assertions based on what these new files do. Tests are beneficial to us maintainers too, so we see how the new features are used. Also, you will be in charge of creating docs, if the PR is accepted. |
Thank you @ematipico for guiding me. Let's proceed like this:
I've already updated the PR description and I kindly ask you to reread it. With this PR a helper function for writing |
Changes
getStaticPaths()
is run in another scope, that makes it impossible to access Astro render context. For some use cases of implementinggetStaticPaths()
, it becomes necessary to know theroutePattern
to calculate the params and props for each page route.For example imagine you have a route
[...locale]/[files]/[slug].astro
and you want to implement agetStaticPaths()
that,[...locale]
[files]
according to the locale, so you can have a path translation[slug]
To lookup what
[files]
should be substituted with, you need to parse theroutePattern
as well as for calculating the translations.This change provides
routePattern
viaGetStaticPathsOptions
. It isn't a breaking change as whoever wants to consume it can, but doesn't need to.A workaround would be calculating this props during rendering of the actual page. For each render
getCollection()
needs to be invoked again. Then I would also wonder whyprops
are returned fromgetStaticPaths()
after all.Example code
[...locale]/[files]/[slug].astro
site.config.ts
translation-path.ts
Testing
I don't know how to test this. I'm very happy to add tests, if you can point me in the right direction.
Docs
/cc @withastro/maintainers-docs for feedback!
The new options should be mentioned in https://docs.astro.build/en/reference/routing-reference/#getstaticpaths.