DataTriny
commented
1 week ago The only downside I see with the JSON serialization being less human friendly is that I'd like UI toolkit developers to use serialized tree updates in non-regression testing at some point, akin to comparing screenshots to detect undesirable changes to styling. But that's only a minor inconvenience and I won't block on it. I'll finish reviewing this soon.
My previous use of serde wasn't compatible with many data formats other than JSON, particularly those that serialize enum discriminants as integers rather than strings, and those that require the size of a map to be specified at the start of serialization.
To solve this, I've refactored the node structs internally. The dynamic properties are now stored in their own struct, and only that struct needs custom implementations of
SerializeandDeserialize.I also made serialization and deserialization more efficient by serializing the bitmasks for the actions and flags directly, rather than serializing the actions as a sequence and the flags as key/value pairs in the outer map.
The serialization to JSON, and similar formats, is now less human-friendly than it was. The dynamic properties are now stored in a sub-object inside the node object, and the actions and flags are now serialized as integers rather than something self-describing. But, in the real-world uses of serialization that are now important to us, like Newton, efficiency is more important than human readability. Newton will almost certainly switch from JSON to a binary format, like postcard or GVariant.