-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The way to integrate the API without depending on ECMAScript realm. #217
Comments
@pmeenan @horo-t @sisidovski FYI. |
@jeremyroman If we could compose |
The correct solution to this is kind of annoying and mechanical. You basically move everything that is currently associated with the 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 Then, the 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 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. |
This is a part of whatwg#217 to make URLPattern match independent from realm. As a first step, dependency to a URLPattern object has been moved to a URL Pattern struct.
To allow the algorithms in the specification to be used outside of JavaScript, we need to remove dependency to JavaScript realm. This CL make a URLPattern object associated with an underlying URL Pattern struct, and makes algorithms to use it instead. Fixes whatwg#217
To allow the algorithms in the specification to be used outside of JavaScript, we need to remove dependency to JavaScript realm. This CL make a URLPattern object associated with an underlying URL Pattern struct, and makes algorithms to use it instead. Fixes #217
Updates in the URLPattern specification was requested during the w3c#1701 review. The issues for the request has been resolved: - whatwg/urlpattern#217 - whatwg/urlpattern#218 However, during the specification updates, the algorithm names are also updated, and adjustment is needed.
…tion (#1707) * Update link texts upon updates in the URLPattern specification Updates in the URLPattern specification was requested during the #1701 review. The issues for the request has been resolved: - whatwg/urlpattern#217 - whatwg/urlpattern#218 However, during the specification updates, the algorithm names are also updated, and adjustment is needed. Co-authored-by: Domenic Denicola <d@domenic.me>
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.
The text was updated successfully, but these errors were encountered: