-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Changed behaviour for optional params #1893
Comments
I added a test but that seems to be working. If that's not what you meant a boiled down reproduction or a failing test would help. I updated the docs too |
Ok I saw it and am a bit confused how that works. Let me look into it. Also wanted to note about the docs again, but seems you were faster 😆 |
The issue occurs when you only want to update the params of the current route, without changing the name:
|
Ah I see, the behavior should be consistent:
No matter the current location. The actual fix is more complicated than it seems because it requires some refactoring so I recommend you to use the documented approach for the moment of using a param with an empty string to remove it |
Ack, we are implementing the workaround right now. |
The fix is a bit more complicated that I anticipated, I will come back to this later on as the currently documented version works perfectly. - the nullish params are removed before being passed to the matcher - The encodeParam function transform null into '' - The applyToParams also works with arrays but it makes no sense to allow null in array params Ideally, I would make the matcher a bit more permissive so the encoding is kept at the router level. I think the matcher sholud be responsible for removing the nullish parameters but that also means the encode function should leave nullish values untouched. We might need an intermediate Type for this shape of Params, it gets a little bit tedious in terms of types, so I would like to avoid adding more types. Close #1893
The fix is a bit more complicated that I anticipated, I will come back to this later on as the currently documented version works perfectly. - the nullish params are removed before being passed to the matcher - The encodeParam function transform null into '' - The applyToParams also works with arrays but it makes no sense to allow null in array params Ideally, I would make the matcher a bit more permissive so the encoding is kept at the router level. I think the matcher sholud be responsible for removing the nullish parameters but that also means the encode function should leave nullish values untouched. We might need an intermediate Type for this shape of Params, it gets a little bit tedious in terms of types, so I would like to avoid adding more types. Close #1893
Reproduction
https://github.com/vuejs/router/blob/main/packages/router/__tests__/router.spec.ts#L300-L328
Steps to reproduce the bug
undefined
Expected behavior
I would have expected the parameter to be unset as in versions before 4.2, but I know this might not have been the intended behaviour.
Actual behavior
This issue is about the changes in #1814
It is a bit of a mess, because several things come together.
undefined
andnull
are stringified: 0c91292Additional information
Whatever the original intented use was, the use-case of unsetting the value of an optional parameter was never properly documented.
In practice using
undefined
worked and was used by us and others, so the change is causing breakages in real-world usages.I checked and unsetting an optional parameter with
""
did work at least in 4.1.6, but I am not sure if it also did in earlier versions, when we first implemented this code.Imho using the empty string as "not set" is bad practice and they should be normalized to
undefined
instead.The text was updated successfully, but these errors were encountered: