The way to integrate the API without depending on ECMAScript realm.
Closed this issue · 3 comments
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.
@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.
@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?
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.