-
Notifications
You must be signed in to change notification settings - Fork 1
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
is JSON.parseImmutable significantly different enough that it deserves its own API? #1
Comments
My initial thought is the rules for authoring and using a reviver could vary depending on the immutable flag and these may be more easily explained by authors and understood by readers when given two distinct parse functions. For example, stating that the following reviver should be used only with let dateFromISOString = (value) => /* if `value` is a valid ISO string return a `Date` else return `null` */;
let reviver = (key, value) => typeof value === "string" && dateFromISOString(value) || value;
let text = '{"title": "Example", "author": "Andrew", "published": "2011-11-18T14:54:39.929Z"}';
console.log(JSON.parse(text, reviver).published.toUTCString()); // "Fri, 18 Nov 2011 14:54:39 GMT" |
An upside to the full dedicated const reviver = JSON.revivers.immutable; // or wherever it is.
JSON.parse(deepObject, reviver); // engine takes fast path
JSON.parse(deepObject, (key, value) => reviver (key, value)); // no fast-path |
@acutmore I'm not suggesting that a built-in reviver would be the solution here. A simple flag would do. JSON.parse(str, { immutable: true }); |
Ah yes, I miss read. Any reason why it would replace the reviver argument, rather than be a new 3rd argument? So someone can still add their own reviver logic into the mix. |
@acutmore To not force a user to provide a reviver when all they want is the immutability behaviour. Making it an options bag still allows a reviver to be provided if desired. JSON.parse(str, { immutable: true, reviver: ... }); |
(copied from tc39/proposal-record-tuple#330)
JSON.parseImmutable seems like it can be expressed as an option given to JSON.parse since it's otherwise identical as far as I'm aware. I see that in tc39/proposal-record-tuple#74 it was originally imagined this way but quickly rejected. But couldn't we take an options bag in place of the reviver and branch on its type?
The text was updated successfully, but these errors were encountered: