Accounting for end: false
in the matcher score
#2153
skirtles-code
started this conversation in
Ideas
Replies: 1 comment
-
I actually wonder if anybody uses |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
While working on #2148, I ran into some problems with
end: false
.I was trying to ensure that my changes didn't impact the matching of routes, even in weird edge cases. In most cases that proved relatively straightforward, apart from for
end: false
.My underlying assumption is that the route ranking mechanism is supposed to ensure that 'more specific' routes come before 'less specific' routes. Generally speaking, that does seem to be how it's implemented.
My PR handles static strings in paths specially. As static strings are 'more specific' than dynamic strings, that usually works out fine, as they'd come earlier in the ranking anyway.
But
end: false
is a notable outlier. It behaves a lot like a.*
wildcard, but it doesn't really get taken into account when calculating the score. It does impact the inclusion of the 'strict bonus' forstrict: true
, but apart from that it's ignored.With enough work, it probably is possible to get #2148 to retain the current sort order for matchers, but it'd likely involve a lot of special handling just for
end: false
. Instead, I think it would be better to change the existing behaviour, so thatend: false
is taken into account in the score.If this idea is acceptable in principle, I'm happy to have a go at implementing it in
pathParserRanker.ts
. This would be separate from #2148, though it should ultimately allow that PR to be completed.Beta Was this translation helpful? Give feedback.
All reactions