Timeline for How do you JSON.stringify an ES6 Map?
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 19 at 9:03 | comment | added | VLAZ |
Yes, this is a good solution since it can produce specific serialisation variations. You can do new MyMap1(someMap) or new MyMap2(someMap) to clone and extend exiting maps easily. And then MyMap1 and MyMap2 can have different serialisation. For example, one might just serialise to a list of tuples, the other to an object. Furthermore, there can be special handling for serialising keys (since those could be arbitrary objects) or similar. The replacer option in JSON.stringify works OK but if it has to handle multiple types, it becomes cumbersome.
|
|
| Apr 5, 2020 at 22:47 | comment | added | Cody |
They don't have to be, but it's a more SOLID way of doing it. Specifically, this aligns with the LSP and OCP principles of SOLID. That is, the native Map is being extended, not modified, and one can still use Liskov Substitution (LSP) with a native Map. Granted, it's more OOP than a lot of novices or staunch Functional Programming people would prefer, but at least it's beset upon a tried & true baseline of fundamental software design principles. If you wanted to implement Interface Segregation Principle (ISP) of SOLID, you can have a small IJSONAble interface (using TypeScript, of course).
|
|
| Apr 5, 2020 at 21:36 | comment | added | vasia | I'm not sure that many will be satisfied with extending the core map class just to serialize it to a json... | |
| Nov 15, 2019 at 17:57 | history | answered | Cody | CC BY-SA 4.0 |