consider exposing URLPatternList

[wanderview]

After the last face-to-face meeting we changed the plan to make service worker scope take a pathname patter string instead of a full URLPattern object and an array of strings instead of a URLPatternList object.

Given this was the main use case for URLPatternList, should we just not expose URLPatternList? Are there other use cases for URLPatternList?

@jeffposnick @jakearchibald do you think developers would need URLPatternList vs simply just managing a list of URLPattern objects themselves?

[domenic]

FWIW, the use cases make sense to me in the abstract still (matching one of many URL patterns). But Jeff and Jake would be better positioned to tell us whether they actually come in practice.

[jeffposnick]

There are FetchEvent routing use cases where you'd want to match against multiple patterns. E.g., matching against multiple CDNs whose URLs are different enough that they can't be combined via wildcards.

So... assuming it's not much more "work" to expose URLPatternList, I think there is some potential value.

[wanderview]

Seems like yes we should include it.

[annevk]

What does it offer beyond a list of patterns? So you can pass it to match rather than pass match an array?

[wanderview]

Basically it would be a convenience to call test() or exec() only once. Also, there might be some future use where we could provide some default sorting for sites that want to use it. For example, #45 (reply in thread).

[wanderview]

After further thought I'm going to postpone working on URLPatternList. I have limited bandwidth and want to focus on getting URLPattern out the door. Since the list offers limited value right now and is completely polyfillable I think we can safely exclude it from the MVP. We can add it later if there is developer demand.

[wanderview]

Note, I opened a separate issue (#61) for ordering of URLPattern objects.

[wanderview]

Developers have pointed out that popular routing systems offer optimized route lookup using data structures like radix trees, etc. For example, see find-my-way. This allows them to find the "best" matching route in a set of routes quickly.

This feels like a compelling feature for URLPatternList or similar container type. We can offer a comparator as discussed in #61 that user space can use to build something like this, but we might be able to do further optimizations if the container can access the intermediate representation directly.

[wanderview]

It would be useful to know how devs feel about these possible features:

• Ability to associate extra data with a pattern in the list that you can access on match. Alternative is to get a ref to pattern on match you can use to look up in your own map.
• Ability to dynamically add to the list. If we have an optimized automatic sort, then we probably would not have normal array-like mutators.
• Ability to dynamically remove from the list.
• Ability to have duplicate equivalent patterns in the list. Perhaps with different group names and/or different associated data, etc.
• Ability to iterate and access indexed entries vs just "find best match for this input".

[intrnl]

I'm speaking mostly in the perspective of app routing, but as URL routing is listed as one of the use cases of URLPattern, I feel that it's necessary for me to chime in.

Being able to provide metadata within the pattern list is necessary, as the pattern result itself wouldn't be enough for us to tell whether it should show view A or B.

I'm not sure about duplicate equivalent patterns under different groups though, I'm not sure if there's any common use case to justify adding this feature specifically?

The rest seems like icing on the cake, so whether or not it makes it in will not make a whole lot of difference, save for dynamically sorted patterns, which may be useful for one feature that's also worth considering...

---

Nested patterns makes it easy to group patterns under the same matcher alongside its metadata, which in the example below, is used to group views under the same layout.

let routes = new URLPatternList([
  {
    // nested routes requires wildcard
    pathname: '/users/*',
    metadata: { component: UsersLayout },
    children: [
      {
        pathname: '/',
        metadata: { component: UsersIndexView },
      },
      {
        pathname: '/@me',
        metadata: { component: UsersPersonalView },
      },
      {
        pathname: '/:username',
        metadata: { component: UsersView },
      },
    ],
  },
]);

The pattern result would contain concatenated groups, and a scope field, as an array containing the metadata of matched patterns.

let match;

if ((match = routes.exec('/users/intrnl'))) {
  match.scope;
  // [ { component: UsersLayout }, { component: UsersView } ]

  match.pathname.groups;
  // { username: 'intrnl' }
}

If parent and children pattern contains a group of the same name, it might be worth throwing early?

This would only be useful for app routers specifically, but it's still something that's worth considering, as app routers would try to reimplement something like this on their own.

---

I believe what I've said would be enough for app routing libraries to justify using URLPatternList for path matching, but it might be worth contacting the authors of React Router and Vue Router to see what they'd say about it. ^^

[posva]

I still haven't been able to give this a test but plan on doing by the end of October.

For Vue router, I would handle the nesting myself and pass a flat array to URLPatternList so I can handle the normalization of the route records.
Adding metadata would be useful, I would have used a Map or something similar to store the component to render based on a url