fix(resolve): exclude empty optional arguments from params

[babu-ch]

fix #2419

Removed if optional parameter is empty
Now the param will match if :to is string and if it is object

In the case of string path, it should not be an empty string parameter(Right?)
, so I thought there would be no problem with excluding it.

However, this may be a breaking change if you have users who were using this

In addition, I added a router-link to Playgound to check the operation.

[netlify]

✅ Deploy Preview for vue-router canceled.

Name	Link
🔨 Latest commit	66f824f
🔍 Latest deploy log	https://app.netlify.com/sites/vue-router/deploys/677e37044abd7e000807f3dd

[skirtles-code]

Can the ?. be changed to . instead?

[babu-ch]

@skirtles-code
Thank you for your comment.
Oh, it was a remnant from writing outside of this block.
Fixed!
66f824f

[skirtles-code]

I was wondering about some other edge cases. I'm not sure whether these necessarily impact this PR, but I thought they were worth considered before it's merged.

I put together this Playground to demonstrate:

• Playground

These are are to relevant values:

1. '/features'
2. { name: 'features' }
3. { name: 'features', params: { id: undefined } }
4. { name: 'features', params: { id: null } }
5. { name: 'features', params: { id: '' } }

All of them lead to the same path.

Clicking around between them, it seems that 2, 3 and 4 are considered equivalent, which makes sense. It's 5 that I found most interesting. It seems to behave like it's a child of 2, 3 and 4.

I also tried with { name: 'features', params: { id: '123' } }, which seems to behave similarly. When that route is active it shows 2, 3 and 4 as active, though not exact active.

Not sure if that's intentional or not, but it doesn't seem to match what's described at https://router.vuejs.org/guide/essentials/active-links.html. I wrote that page, so I may be to blame for describing these classes incorrectly. It seems that there's some special handling for optional params that I didn't take into account in my description.

[posva]

FYI in the upcoming custom resolvers I'm trying to introduce a consistent behaviour. Right now I'm going for this: optional params are always null if missing (not passed, empty string, undefined, null). It's working well and the only issue I can see is that the empty string could also be simply rejected rather than transformed to null but it sounded less convenient. Open to suggestions!