refactor: replace route's format with pattern in [StaticBadge] & modified [website]#11865
refactor: replace route's format with pattern in [StaticBadge] & modified [website]#11865jNullj wants to merge 7 commits into
route's format with pattern in [StaticBadge] & modified [website]#11865Conversation
…or invalid content
label--blue and label- -blue produce the exact same results. our docs indicate -- outputs - so the label--blue syntax is not consistenet with our docs for use in missing message, and is more confusing considering our logic here.
|
A few things to consider in the review
why brake support for missing message? i hate it being a braking change, but i think its not in wide use, look at this search over github only 262 results show up and this include all -- usage, most of them are for 3 parts usage and are not relevant to this change |
route's format with pattern in [static-badge] & modified [website]route's format with pattern in [StaticBadge] & modified [website]
There was a problem hiding this comment.
this is undocumented, so i think its better as a redirect with its own path rather then adding logic to usage of badgeContent of the service
|
|
||
| t.create('Missing message') | ||
| .get('/badge/label--blue.json') | ||
| .get('/badge/label-%20-blue.json') |
There was a problem hiding this comment.
This is hardly in use, users get the exact same result using a space - - instead of --.
This was not consistent with our docs and logic of escaping -- => -. So i find the that confusing and think we should drop support. for label--color syntax in favor of using label- -color
| ) | ||
| } | ||
|
|
||
| function splitDashSeparatedOptionalParams(s) { |
There was a problem hiding this comment.
This is now a helper function shared with Website
static-badge is the LAST to have format transformed to pattern!
after this is done and merged i will create one last PR to remove all code, tests and docs related to the old deprecated
formatthen we could complete #3329.i modified the code in website as well to reuse the same code in an helper module and added tests.
we should consider performance here as well
i suspect that
splitDashSeparatedOptionalParamscould in theory be faster then regex, but i should test this to be sure, maybe regex libs has some optimization im not using, maybe we could optimizesplitDashSeparatedOptionalParamssomehow.other changes:
label--bluewhich is still supported with the same render usinglabel- -blue(not in wide use)