feat(nuxt): Parametrize SSR routes #16843
Conversation
s1gr1d
force-pushed
the
sig/param-routes-nuxt-ssr
branch
from
ea09c04 to
8492c82
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
I still need to look into why this is failing in |
| } | ||
|
|
||
| const method = ssrContext?.event?._method || 'GET'; | ||
| const parametrizedTransactionName = `${method.toUpperCase()} ${routeInfo.parametrizedRoute}`; |
There was a problem hiding this comment.
m: We create the parametrizedTransactionName but don't update the span name?
There was a problem hiding this comment.
oh that's left from before the last commit 😅
was using updateSpanName before, but I only need to set 'http.route': routeInfo.parametrizedRoute to update the name.
| * An array of NuxtPage objects representing the build-time pages data. | ||
| * Example: [{ name: 'some-path', path: '/some/path' }, { name: 'user-userId', path: '/user/:userId()' }] | ||
| */ | ||
| export function extractParametrizedRouteFromContext( |
There was a problem hiding this comment.
l: should we memoize this function?
There was a problem hiding this comment.
Yeah the function is quite expensive as the lookup is hard :/
I added some general, small optimizations for the function.
Using the currentUrl is not possible as it includes the parameters and that would blow up.
And the only way to memoize the result is using the ssrContextModules as key (which is quite complex as this can be a large Set) and this Set has a different reference, every time a request is sent. So the key has to be created on every request, as I cannot use the Set itself as a key.
However, as I think the key generation regardless its overhead still makes sense, I added it now.
packages/nuxt/src/module.ts
Outdated
| }); | ||
|
|
||
| nuxt.hooks.hook('pages:extend', pages => { | ||
| pagesDataTemplate.getContents = () => `export default ${JSON.stringify(pages, null, 2)};`; |
There was a problem hiding this comment.
m: So stringifying all of the pages can get pretty big from what I can see in the NuxtPage type.
Perhaps we should just save a subset? We really only need the file and the path from looking at extractParametrizedRouteFromContext.
There was a problem hiding this comment.
Good catch, I also filtered for only dynamic pages.
# Conflicts: # dev-packages/e2e-tests/test-applications/nuxt-3-dynamic-import/tests/tracing.test.ts # dev-packages/e2e-tests/test-applications/nuxt-3-min/tests/tracing.test.ts # dev-packages/e2e-tests/test-applications/nuxt-3-top-level-import/tests/tracing.test.ts # dev-packages/e2e-tests/test-applications/nuxt-3/tests/tracing.test.ts # dev-packages/e2e-tests/test-applications/nuxt-4/tests/tracing.test.ts
s1gr1d
force-pushed
the
sig/param-routes-nuxt-ssr
branch
from
9aff99a to
b3bbf0c
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
Great work! Had some questions about our matching algorithm. IIUC we need a similar logic in Next and possibly other frameworks at some point. Might make sense to think about extracing this in the future because matching routes is far from trivial. But obviously this is a something to follow up on later :)
| file: '/app/pages/test-param/[param].vue', | ||
| }), | ||
| ], | ||
| expected: { parametrizedRoute: '/test-param/:param()' }, |
There was a problem hiding this comment.
l/q: what's the reason for the brackets in the parameters (:param_()_)? Is this a Nuxt routing covention/something users are used to?
| }); | ||
|
|
||
| describe('multiple routes matching', () => { | ||
| it('should find the correct route when multiple routes exist', () => { |
There was a problem hiding this comment.
sticking with this example: If I have two routes,
file: '/app/pages/test-param/user/[userId].vue',
file: '/app/pages/test-param/user/abc.vue',
do we still correctly identify the respective routes for urls /test-param/user/123 and /test-param/user/abc?
(Sorry in case I missed such an example in already existing tests. If not, it might be a good test case)
There was a problem hiding this comment.
Related but not also rather a question: Does this handle catch-all routes?
Adds route parametrization to SSR server routes.
The parametrized route data is gathered during build time and saved in a virtual file (added with
addTemplate) which can hand-over the data to be accessed during runtime.The
nuxt-3-mintest (Nuxt 3.7) shows that the route parametrization does not work yet with this version. From Nuxt 3.9 onwards, it works. This is fine, as most people are on a more recent version anyways.part of #16684