-
-
Notifications
You must be signed in to change notification settings - Fork 163
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
Serialize + Parse Map Objects #823
Comments
When call the native Therefore, it is not invalid serialization, but following the standard feature. const map: Map<string, number> = new Map();
map.set("first", 1);
map.set("second", 2);
const str: string = JSON.stringify(map);
console.log(str);
|
I see, would you be opposed to me adding a custom case for serializing Maps? Or should users of Typia define their own custom Map-like class to perform equivalent serialize and deserialize? At the very least, emitting a warning might be helpful, something along the lines of
|
I started down the path of "how would I implement serialize + parse?" I dug into src/programmers/json/JsonStringifyProgrammer.ts but then realized that A possible solution would be to create a replacer function and pass it to all invocations of Example replacer function: let replacer = (key,value) => {
if(value.__proto__.constructor == Map) {
let s = [];
value.forEach((v,k,m) => { s.push([k,v]); });
return s;
}
return value;
}
let m = new Map([["hello","world"]]);
console.log(JSON.stringify(m, replacer)); // Outputs '[["hello","world"]]' However, adding this would make Typia's JSON serialization not match If you do feel strongly about a potential difference between Typia and I am willing to implement this but just want your approval before I begin working on it. |
Not possible to supporting the custom replacer function through Also, I'm hoping This is just my opinion at now - I think it would better to throw a compilation error when such |
Error or warning messages would be good then. I can see the desire to adhere to In the end, I really should just convert all of my |
Close #823 - ban Map types on JSON functions.
📝 Summary
Right now I am finding that if
typia.json.stringify()
is used on an interface that has aMap
object results in incorrect serialization, and most likely incorrect parsing as well.typia.json.stringify()
produces a string representation of the Map object{}
with no items⏯ Playground Link
https://typia.io/playground/?script=JYWwDg9gTgLgBDAnmYBDOAzKERwORIqp4DcAUGcAHYwCmUGqAxrXALKICSN9jLcAbzJwRcEAC52qMAB4AzjCjUA5gBoFSqsoB8ZAL4UANrXipJHbnQbNWAXkFjJVWgHcpsjStVxPW7QAoASjg9clQAOhBwuRN-ACI6BTjVONQAIyYAE1oMOMDyMmN4ACs5CCoAfV9lOHtCNHDS8ujFFWAMRBkLHmsWANR8siZysuNwwwhleIApAGUAeQA5H1atSTi4AGo4JsrqwaK4MFQoGMzzLh6+OwRkBt3w1DkY2AAFE5iuy6trgN2q1bKQbDKijWjjSbxd6nVguaAAa1omQAhHlyCCwRCpscYZlItFgAAvWj5IA
💻 Code occurring the bug
Map objects can use many different types for keys and values (see the MDN docs). But I think the most valuable for Typia to support would be string keys and values, as well as other basic primitives (integers/numbers, boolean values).
The text was updated successfully, but these errors were encountered: