Closed warriordog closed 1 year ago
This is actually a ton of effort, so here's a revised approach:
[CustomJsonDeserializer]
attribute that can be placed on a method to perform custom deserialization logic.
static bool TryDeserialize(JsonElement element, JsonSerializerOptions options, out TThis? obj);
[CustomJsonSerializer]
attribute that can be placed on a method to perform custom serialization logic.
static bool TrySerialize(TThis obj, JsonSerializerOptions options, out JsonNode? node);
ASTypeConverter
is modified to no longer be re-entrant. Instead, it works like this:
JsonElement
typeToConvert
and the JSON dataCustomJsonDeserializer
, then call it.CustomJsonSerializer
, then call it.JsonNode
to the output streamASTypeRegistry
will be updated to store metadata for all of the above attributes and properties.This approach has several downsides:
ASType
JsonConverters
wont work with ASType
without additional workBut it has several upsides, too:
ASType
ASLink
.Open questions:
ASCollection
requires a custom converter.
The JSON-LD model, as currently designed and implemented, will not and can not work due to this open issue in
System.Text.Json
: https://github.com/dotnet/runtime/issues/63791. Until that feature gap is resolved, we will need to fall back to a lower-level implementation. This is the proposed fallback:System.Text.Json
as usual.Serialize
andDeserialize
methods, which will work with JsonNode/JsonElement respectively.Read
andWrite
. Read will populate an existing object from a reader, and write will write properties into a pre-initialized JsonObject. These will allow serialization logic to be "inherited" by calling into the base class members.This rewrite will be completed in the
sample-app
branch. Work will be considered done when the sample app is able to query a simple object from a remote instance.