Comments (17)
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.
from urlpattern.
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.
from urlpattern.
I believe you can
JSON.stringify(urlpattern)
and thennew URLPattern(JSON.parse(stringified))
.
Unfortunately this doesn't quite work for at least two reasons:
- JSON.stringify(...) returns '{}' for URLPattern (it has no own properties, and no special JSONification).
- This would also drop options like
{ignoreCase: true}
.
from urlpattern.
I'm not sure I will get to this in the first iteration, so tagging as an enhancement.
from urlpattern.
URL is not serializable, why should this be? Can it not be serialized to a string?
from urlpattern.
Hmm yeah, see also whatwg/url#370
from urlpattern.
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?
from urlpattern.
I think the main reason is that you can use strings already.
from urlpattern.
A string isn’t guaranteed to be a valid URL - isn’t this akin to the entire motivation for trusted types?
from urlpattern.
Again, I'm not sure those URL properties apply to URLPattern.
from urlpattern.
URLPattern cannot be serialized?
from urlpattern.
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.)
from urlpattern.
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.
from urlpattern.
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
.
from urlpattern.
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.
from urlpattern.
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:
- 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.
- 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 whatwg/html#4914 is addressed. As I touch on in #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.
from urlpattern.
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.
from urlpattern.
Related Issues (20)
- Base URL inheritance gives unintuitive results HOT 21
- Consider creating a RFC for base functionality HOT 2
- Add a "using URLPattern in other APIs" section HOT 9
- Backslash escaping is required for colon before password in string syntax
- WHATWG migration HOT 5
- Attribute to show the regular expression usage. HOT 9
- Hash test matching different from path matching HOT 1
- Consider cleaning up extra markdown documents
- Custom named full-wildcard HOT 2
- Base URL and empty pathname in URLPatternInit
- Incorrect handling of base URL in URLPatternInit processing HOT 10
- Loose base URL check can crash URL parser HOT 5
- Handling of special character in hostname
- More consistent and robust segment wilcard generation
- Incorrect type in group name assignment
- "Hostname pattern is an IPv6 address" called with `null` HOT 1
- Constructor string parser has confusing result for paths containing a colon. HOT 1
- The way to integrate the API without depending on ECMAScript realm. HOT 3
- Accept URL as the match algorithm's input. HOT 4
- Opaque Host and domain encoding HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from urlpattern.