Cannot read properties of undefined @ router normalizePath
Hi!
My issue is the one described up here in the title.
The function that throws it is @solidjs > router > dist > utils.js > normalizePath.
I temporarely patched it going from this:
To this:
(Simply adding a '?' before .replace)
The structure of my webapp (where this issue happens) is the following:
=> Layout: (logged).tsx
=> And the page where the issue happens: index.tsx:
Am I doing something wrong?
Thanks : )
6 Replies
Are you saying you are attempting:
instead of
???
Hi.
Thanks for anwering. I think it's better if I share directly a screenshot of it.
(The api folder was renamed to _api just for the sake of the screenshot)
I wonder if
was actually meant to be
Hey! Sorry for the late response.
I actually wanted to have every file named differently since I have an API endpoint called opportunity too.
If I'm not mistaken it's fine to call it in that way just for a sorting purpose.
The issue I'm experiencing happens in index.tsx.
For example, removing the "?" from the file I've described previously triggers the error you can see in the image
If I'm not mistaken it's fine to call it in that way just for a sorting purpose.I'm not convinced that is an option. The route naming conventions align with the way the route components would be organized within the router tree. What are you even trying to express here?
[opportunity]
is a path param for a dynamic route.
But I would expect that to be followed by either a file extension (.tsx
) or path delimiter (/
); the following (path).tsx
makes no sense to me.
I'm exploring the possibility that the source code is correct, i.e. that path
should never be undefined
and that an ill-formed route specification manifests as the path being undefined
.I had multiple files named [opportunity] (in routes and routes/api) and I wanted to differentiate between them.
But if there's no way for doing so it's fine : )
Regarding the issue that I had before:
I used a template for simulating some API calls.
When I switched to actual APIs the error doesn't happen again...