-
Notifications
You must be signed in to change notification settings - Fork 142
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
toJSON() serialization #137
Comments
|
The individual components don't show up with |
I think you're referring to something Chrome used to do at some point, not the standard way it's supposed to work. |
@annevk Are you saying the spec shouldn't define a default and should just always return |
Firefox v48 stringifies all properties/getters, but whatwg-url does not. |
Then Firefox is not following the spec for JSON.stringify. I suspect something else is going on. |
Yes. I think @annevk is confused. The JSON.stringify spec is unambiguous. |
console.log( JSON.stringify(new Date()) ) produces:
|
I didn't say that Firefox stringifies all properties/getters? All I was saying that we could define something here, but it's not clear to me what the best option is. |
Having a |
If |
@annevk when serializing the JSON.stringify({ key: new URL("http://domain/") }); |
@tobie would we just define |
@annevk right, that's being discussed in whatwg/webidl#188. Haven't looked into it myself yet. |
Apparently it is currently disallowed to create an operation named toJSON:
So I guess the way to currently do this would be to just define |
In terms of the current IDL spec, you can write:
to get the desired behavior, no? But as mentioned in whatwg/webidl#188 I think the current spec is way overdesigned. |
This allows whatwg/url#137 to move on.
This allows whatwg/url#137 to move on.
This allows whatwg/url#137 to move on.
This makes it a little easier to use with JSON.stringify(). Fixes #137.
I created a PR for this, #229. Please review! Will write a test too. |
Standard discussion: whatwg/url#137.
I agree with @stevenvachon. As an end user, I would expect a URL to serialize to the full During deserialization, the user can pass the string into the Here's an example: var data = {
theUrl: new URL("https://example.com/foo"),
theDate: new Date("2017-02-02T17:06:41.229Z")
};
var str = JSON.stringify(data);
// "{"theUrl":"https://example.com/foo","theDate":"2017-02-02T17:06:41.229Z"}"
var clone = JSON.parse(str);
new Date(clone.theDate).valueOf() === data.theDate.valueOf(); // Current this is true
new URL(clone.theUrl).href === data.theUrl.href; // I would expect this to be true Note that the Date does not stringify as |
Standard discussion: whatwg/url#137.
This makes it a little easier to use with JSON.stringify(). Tests: web-platform-tests/wpt#4702. Fixes #137.
Browser bugs (none for Edge as it doesn't implement the API yet): |
It was pointed out to me Edge does implement the API! Oops. I filed https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10867624/ on Edge. |
This just landed in node.js 7.7.0 today 🎉 |
I think it'd be handy if all
URL
instances would serialize to the value ofhref
.The text was updated successfully, but these errors were encountered: