In Unity Serialization 1.7.0-preview.1 when implementing a Deserialize method for a custom Json adapter, is there a way to “fall back” on the default deserialization method implemented by the package? Errors are propagated (as they should be) and null/default values will be treated as the result of deserialization (as they should be).
Simple example:
public Item Deserialize (SerializedValueView view) {
// Treat a float in the JSON as a shorthand for an item with value equal to that float
try {
return new Item { value = view.AsFloat() };
}
catch (InvalidOperationException) {}
// Fall back on however the serialization package would have parsed it, e.g. for JSON like { "value": 52.1 }
return ????
}
Currently we do not support this feature. The assumption is that if an adapter is implemented the type is fully handled by that adapter.
In the next release we are improving this API to allow continuing serialization, re-entrance, and adapter stacking. The adapters will provide a context object which gives access to the underlying serialized object or writer along with some API calls to help handle specialized cases.
Item IJsonAdapter<Item>.Deserialize(JsonDeserializationContext<Item> context)
{
try
{
return new Item { value = context.SerializedValue.AsFloat() };
}
catch (InvalidOperationException)
{
return context.ContinueVisitation();
}
}
With the new context object you will be able fallback on the default implementation, or even pass control to other adapters. You will also be able to re-enter the deserialization flow for any sub objects within the adapter
(e.g. You may want to deserialize a nested object, read some values, compute some values based on this, then return your object).
The new API is pretty much finalized and we are going through testing a preparing a package release. I can’t say when it will be available in dots package as we need to update the dependency and make it in to a release, this could be one or two versions out.