make URLPattern and URLPatternList serializable/structured cloneable

[wanderview]

During the call in w3c/ServiceWorker#1535 @asutherland asked if these types will be serializable. I interpreted this as asking if they can be structured cloned. I think it makes sense to so and we should include it in the proposal.

[asutherland]

To clarify, yes, you interpreted this right, but I think the current HTML spec terminology (and WebIDL attribute) is serializable, and the term cloneable is legacy but reflected in terminology used in engines.

[wanderview]

I'm not sure I will get to this in the first iteration, so tagging as an enhancement.

[annevk]

URL is not serializable, why should this be? Can it not be serialized to a string?

[domenic]

Hmm yeah, see also whatwg/url#370

[wanderview]

AIUI, the reason for not serializing/cloning URL objects is that they have mutable attributes. Is that true?

URLPattern objects are immutable.

Are there other reasons why URL is not serializable or structure clonable?

[annevk]

I think the main reason is that you can use strings already.

[ljharb]

A string isn’t guaranteed to be a valid URL - isn’t this akin to the entire motivation for trusted types?

[annevk]

A URL instance also isn't guaranteed to be a valid URL (it only guarantees it's parseable). But since the receiver can mutate it I'm not sure if that property really buys you much.

[wanderview]

Again, I'm not sure those URL properties apply to URLPattern.

[annevk]

URLPattern cannot be serialized?

[wanderview]

Maybe I misunderstood. I thought you were arguing URLPattern should not be serializable/clonable because URL is not serializable/clonable. But AIUI that restriction on URL is because its mutable, but URLPattern is immutable. (Maybe this is only an issue for cloning.)

[domenic]

I think Anne was arguing that URLPattern should not be serializable/cloneable because you can just send its toString() version across and reconstruct on the other side, which is a similar story to URL.

My personal feeling is that this is an argument for deprioritizing the work, but not against the work.

My general stance on cloning/serializing is that we should probably do it a lot more across the web platform. But, since we don't today, it can be a bit strange for one API to come out and add serializibility. I can understand the fear that maybe we'll end up with a strange lumpy platform where what's serializable largely depends on the initiative of individual proposal authors.

[domenic]

because you can just send its toString()

This is actually not true; I didn't realize. I think this has been discussed before, but I can't find it... Basically there is currently no algorithm for serializing an arbitrary URLPattern to a string, only for going from string -> URLPattern.

[wanderview]

I believe you can JSON.stringify(urlpattern) and then new URLPattern(JSON.parse(stringified)). Basically the URLPattern has the same form as the URLPatternInit dictionary, so if you can serialize it as an object it should predictably recreate the pattern.

I expect @asutherland might prefer something more efficient than this, though.

[jeremyroman]

I believe you can JSON.stringify(urlpattern) and then new URLPattern(JSON.parse(stringified)).

Unfortunately this doesn't quite work for at least two reasons:

1. JSON.stringify(...) returns '{}' for URLPattern (it has no own properties, and no special JSONification).
2. This would also drop options like {ignoreCase: true}.

[asutherland]

I expect @asutherland might prefer something more efficient than this, though.

I don't have a concern about efficiency. But I do have 2 different concerns:

1. Developer ergonomics. URLPattern feels very much like a data primitive and it seems like hostile API design when putting a data primitive in a postMessage payload will suddenly cause the call to postMessage to throw. I hate responding to bug reports where a developer got bitten by something like this and my answer might as well start with "Well, actually...". The URL situation feels very similar; I understand why it doesn't make sense to let someone structured serialize/transfer an IDBTransaction instance because it's mutable, but it feels pedantic in the case of URLs. This also complicates encouraging developers to move things off the main thread and into workers.
2. Ensuring web-compat for APIs that use URLPattern like ServiceWorkers by making it possible to specify a cross-browser concept of size for URLPattern, at least once Augment structured serialize algorithm to optionally compute a canonical serialized length to allow cross-browser consistent data limits html#4914 is addressed. As I touch on in consider maximum scope size #18 (comment) there are 2 storage-related concerns that come up with potential uses of URLPattern: a) web-compat and b) avoiding allowing sites to abuse things that are not meant to be synchronously available storage APIs as sync storage APIs. Web-compat is the critical thing, though, and so it would be nice to make sure that we can specify per the WHATWG infra spec algorithm limit suggests a minimum size on URLPattern support across browsers. Since the meta concern is storage/memory size rather than arbitrary algorithm limits on specific fields, supporting structured serialization is a nice way to capture the size limits in a single value.

[annevk]

I don't necessarily disagree, but also whatwg/url#370 had like no demand in a period of five years whereas other URL API features were repeatedly requested over that same time period. Given that we have finite time, I'm not sure I'd invest it here.