Skip to content
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

Accept URL as the match algorithm's input. #218

Closed
yoshisatoyanagisawa opened this issue Feb 15, 2024 · 4 comments · Fixed by #221
Closed

Accept URL as the match algorithm's input. #218

yoshisatoyanagisawa opened this issue Feb 15, 2024 · 4 comments · Fixed by #221

Comments

@yoshisatoyanagisawa
Copy link
Contributor

yoshisatoyanagisawa commented Feb 15, 2024

What is the issue with the URL Pattern Standard?

In the ServiceWorker static routing API (w3c/ServiceWorker#1701), the match algorithm is used for matching with a request URL, which is a URL. However, the specification expects either of USVString or URLPatternInit as its input now.

To fill the gap, we may need to make the match algorithm accept URL.

@yoshisatoyanagisawa
Copy link
Contributor Author

Since URL is struct, we may need to do #217 before this?

@jeremyroman
Copy link
Collaborator

From a JS perspective, this works because URL suffices for a URLPatternInit dictionary (it exposes the necessary properties). If you're interested in calling this from another spec (rather than being concerned about the JS interface), maybe it would be convenient to have a spec helper which accepts URL records, sure.

@yoshisatoyanagisawa
Copy link
Contributor Author

Just FYI, but it was pointed out in https://github.com/w3c/ServiceWorker/pull/1701/files#r1484898361 while calling match for the ServiceWorker static routing API.

yoshisatoyanagisawa added a commit to yoshisatoyanagisawa/urlpattern that referenced this issue Feb 27, 2024
The original specification did not explicitly accept a URL object as an
input, and expected implicit conversion from the URL object to the
URLPatternInit object for matching.

This change make the URL object accepted as an input explicitly.
This is a step to fix whatwg#218.
@yoshisatoyanagisawa
Copy link
Contributor Author

I have updated the description to clarify that the match algorithm change is needed for the SW static routing API.
Making test() or exec() to accept the URL object is out of the scope because as @jeremyroman touched in #218 (comment), it is actually not needed for the external APIs.

sisidovski pushed a commit that referenced this issue Feb 29, 2024
In w3c/ServiceWorker#1701, the ServiceWorker static routing API uses the match algorithm to match the request URL. However, the original match algorithm accepts a URLPatternInput object, and it does not accept a URL struct. To allow the ServiceWorker static routing API to use the match algorithm, we need to make the match algorithm to accept the URL struct.

Fixes: #218.
yoshisatoyanagisawa added a commit to yoshisatoyanagisawa/ServiceWorker that referenced this issue Mar 4, 2024
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.
mkruisselbrink pushed a commit to w3c/ServiceWorker that referenced this issue Mar 13, 2024
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants