whatwg / urlpattern

URL Pattern Standard
https://urlpattern.spec.whatwg.org/
Other
157 stars 22 forks source link

The way to integrate the API without depending on ECMAScript realm. #217

Closed yoshisatoyanagisawa closed 8 months ago

yoshisatoyanagisawa commented 8 months ago

What is the issue with the URL Pattern Standard?

In, 4. Using URL patterns in other specifications, there are two ways to integrate the URLPattern API. However, both of them depends on the ECMAScript realm.

Considering the integration with the compression dictionary transport and the ServiceWorker static routing API, it may not be feasible because they may not have the ECMA realm on the pattern creation or execution.

We need the way to integrate the API without the realm dependency.

yoshisatoyanagisawa commented 8 months ago

@pmeenan @horo-t @sisidovski FYI. I suppose the compression dictionary transport and the SW static routing API do not want URLPattern to depend on the realm.

sisidovski commented 8 months ago

@jeremyroman If we could compose pattern without "new URLPattern" in the step 2.1 and 3.2 build a URLPattern from an Infra value, can we drop realm here?

domenic commented 8 months ago

The correct solution to this is kind of annoying and mechanical.

You basically move everything that is currently associated with the URLPattern object to a separate "URL pattern" struct. These are manifestly realm-independent.

Then you update all the algorithms possible to operate on the URL pattern structs. Especially, the ones that are exported from this spec for public use by other specs. This includes creating some new algorithm, e.g. "create a URL pattern", which is a variant of "initialize a URLPattern" which creates a new URL pattern struct from appropriate values, instead of operating on a created URLPattern object.

Then, the URLPattern object gets an internal "backing URL pattern", which is an instance of the URL pattern struct type.

Then, everything in the public API forwards to "this's backing URL pattern".

You can see this pattern in action, for example, in how https://fetch.spec.whatwg.org/#request-class lists Request as having an associated request, which is an instance of the request struct. (It's not explicitly declared as a struct, but it's the same thing.)

The fact that this pattern is kind of annoying and mechanical means that, to me, it's pretty obvious how the spec is "supposed" to work right now. But cleaning this up would be a good idea, eventually.