[legacy-framework] Add autogenerated Routes manifest for use with <Link> components
#2042
Conversation
This stage creates a manifest about all routes.
For the Auth example, this is what it looks like:
```ts
export default {
Home: "/",
Test: "/ssr",
ForgotPasswordPage: "/forgot-password",
LoginPage: "/login",
ResetPasswordPage: "/reset-password",
SignupPage: "/signup",
ShowProjectPage: ({ projectId }: { projectId: string }) => `/projects/${projectId}`,
ProjectsPage: "/projects",
NewProjectPage: "/projects/new",
EditProjectPage: ({ projectId }: { projectId: string }) => `/projects/${projectId}/edit`
}
```
This can be imported from user code to use as described in #2023.
|
Size Change: +4.57 kB (+2%) Total Size: 239 kB
ℹ️ View Unchanged
|
|
Alright, so now the route manifest is generated into export default {
Home: "/",
Test: "/ssr",
ForgotPasswordPage: "/forgot-password",
LoginPage: "/login",
ResetPasswordPage: "/reset-password",
SignupPage: "/signup",
ShowProjectPage: ({ projectId }: { projectId: string }) => `/projects/${projectId}`,
ProjectsPage: "/projects",
NewProjectPage: "/projects/new",
EditProjectPage: ({ projectId }: { projectId: string }) => `/projects/${projectId}/edit`
}For our last TODO "Do TypeScript shenanigans to allow importing from blitz", I need some inspiration. What's the best way of making the manifest accessible to devs? |
Follow same approach as prisma, which I expect is adding this to export {default as Routes} from '.blitz/route-manifest.ts' |
|
Adding For housing the stubs, we could create a new package called Another solution would be to add a post-install script to Prisma has a proxy package What do y'all think about this? It's not a decision that would require a breaking change in the future, so we don't need to ponder that long about it ^^ |
|
I've decided to resemble Prisma: We're still generating into There's two problems that need to be solved, though:
|
|
Yeah, I think do exactly what Prisma does unless we have a good reason not to. Also I would copy their code exactly as much as possible, because they have fixed a lot of things like postinstall not working in monorepos etc. What exactly is the error with On the command naming: My feeling is that we should use Here's some ideas I think I quite like |
|
I suspect the |
|
We also need to add docs for this. And update the |
|
Some thoughts that occurred to me while writing the docs:
|
Great point. Probably we should do this. And type the function so that if it's a dynamic route, the route param is required but also any key/value can be passed.
This also sounds like a good idea.
I'm thinking we should stick with Routes so it leaves the door open for other things besides strictly pages. Also, are we generating the manifest on P.s. you have a merge conflict |
Yes, we already do. The generation mechanism reads from the normal pipeline, but instead of writing back into the pipeline it writes directly to |
I can't fix this locally (tried running |
flybayer
changed the title
Routes manifest for use with <Link> components
It does return that object now and I'm really unsure how to mark link as active based on asPath or pathname from useRouter and this {pathname: 'somepath/[slug]', query {slug:'whatever'} |
|
I'm trying to make ActiveLink work (not using 'as'). It does work if href is a string but I couldn't find an easy way to make it work with href = URL object like { pathname: "/products/[pid]", query: { pid: 123 } }. Can't find any exposed utils to convert it back to string to compare to asPath. |
itsdillon
changed the title
Routes manifest for use with <Link> componentsRoutes manifest for use with <Link> components
Closes: blitz-js/legacy-framework#513
What are the changes and their implications?
Give users a Route manifest as described in blitz-js/legacy-framework#513.
ToDo:
Checklist