What does Scope Match ordering means?

[posva]

Hello,

Reading https://github.com/WICG/urlpattern/blob/master/explainer.md#scope-match-ordering it makes me understand there is a way for different instances of URLPatterns to be ordered or that there is a different entity that is able to, given a list of instances of URLPatterns and a url string /users/20, match the most specific URLPattern.

Is this what that part means?

I'm asking because this would be necessary for JS dynamic client side routing which seems to be one of the use cases and could potentially enable client side routers to take advantage of the API

[wanderview]

That specific section in the explainer is talking about ordering specifically for the service worker API. It has its own rules of how things must be ordered.

We are also planning to have a URLPatternList object that would be an ordered list of URLPattern objects. The ordering would be determined by how you create the list, though. We weren't planning on automatic ordering based on rules like SW scopes for URLPatternList.

Does URLPatternList solve your use case? Or is it more you need the automatic order determination like service worker scopes uses that you need?

[posva]

Thanks for the explanation! Automatic order determination like in service workers is what I meant (Sorry, I didn't know that was a thing) and yeah, that would be definitely useful!

For Vue Router, I found myself implementing a scoring mechanism to rank paths (https://paths.esm.dev). Because of the implementation, it has its caveats but it's a necessary part of the Matcher in the client-side routing

[wanderview]

I guess I wonder if the ordering would really be generic or if different routers would want different criteria.

[posva]

I don't see a reason for it not to be generic. If it follows the criteria used by scope match ordering in service workers, that would be enough

[wanderview]

It might be difficult to make generic. The service worker case leans on the restrictions we plan to place on what patterns can be used for scopes. For example, you cannot have any custom regexp groups, etc.

I guess its not clear to me what ordering makes sense in the general case. We could add something, but maybe it could come later after we see how people use the API.

[posva]

Yeah, I don't think it is possible to create something generic that works in every situation. That's why I thought using the one that already exists would be good.

In my experience with client side routing, limiting the possible patterns to enable automatic ordering is very welcomed as it enables adding and removing patterns on the flight. Without it, adding a pattern like /:id and then /help would never match /help. It becomes way more complicated with patterns like /some-:a-foo-:b-:c

[wanderview]

This is now being discussed in issue #61.