Closed skirtles-code closed 7 months ago
Name | Link |
---|---|
Latest commit | ff140d1693950a572ea74c28114b3174ff04137a |
Latest deploy log | https://app.netlify.com/sites/vue-router/deploys/65e6a915ff44d90008ae6f74 |
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 91.01%. Comparing base (
13303bd
) to head (ff140d1
). Report is 3 commits behind head on main.
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
This PR attempts to improve the warnings and error handling for a common problem encountered during development.
Background
There's an error message I've encountered several times on Vue Land:
This comes from
router.resolve()
, e.g.:That's a silly example, it's rarely quite so obvious when someone is having this problem in a real application.
These two issues are both hitting the same problem (the first one is in the wrong repo):
You get something similar with
null
instead ofundefined
.router.push(undefined)
gives the same error, as that usesrouter.resolve()
.Most commonly this is hit via
useLink()
. Here's a simple example of that:Again, I've made it obvious what the problem is with
to: undefined
, but real code is rarely so blatant.It is possible to hit this same error via
RouterLink
, but in that case we get a prop validation warning, making it a bit easier to figure out what the problem is:The mistake in that example is a typo in
patn: '/about'
.But even with the prop validation warning, it can be difficult to identify exactly which component has the problem. If we could inspect the components using Vue Devtools it'd be much easier, but that isn't currently an option because rendering bombs out.
The Vuetify problem
Someone on Vue Land was hitting this error, but without any warnings to indicate what they were doing wrong. They weren't using
RouterLink
, they were using Vuetify's breadcrumb component.The ultimate cause of the problem was an
undefined
in their data that they hadn't taken into account. But this isn't quite as simple as it sounds.There's this problematic line in Vuetify:
The problem here is that
props.to
can beundefined
. While the Vuetify composable does check that, it only checks the initial value. In the application we encountered on Vue Land, theto
prop was populated initially, only becomingundefined
after some new data loaded.It isn't obvious to me how Vuetify could fix this problem in their own code. There doesn't seem to be a way to disable the
useLink()
composable when the prop isundefined
and re-enable it when the value is defined.This PR doesn't attempt to address that problem directly, it just aims to improve the warnings/errors to ease debugging.
What's changed
router.resolve()
no longer throws an error in dev. It logs a warning instead. This allows Vue Devtools to be used to debug the problem.useLink()
logs warnings. This is usually a bit more helpful than the warning inrouter.resolve()
, as it has more context to work with.props.to
is invalid, making it much easier to find a rogueRouterLink
in a long list:In cases where
RouterLink
has anundefined
ornull
value forto
, this will lead to 3 warnings being shown: one for prop validation, one foruseLink()
and one forrouter.resolve()
. I couldn't see an easy way to avoid that, but I think that's much better than not having the warnings.