Add serialization support for System.Text.Json (Attempt #2)

[akaegi]

Second attempt for System.Text.Json support.
Should close #901.

Tried to adress issues mentioned by @chucker in #905 (thanks!).
The problem lies in non-polymorphic deserialization IMO. The original deserialization failed when the constructor had an IQuantity subtype as argument (e.g. Information) but the converter converted to IQuantity. I addressed that by returning specific converters in the factory as described in https://docs.microsoft.com/en-us/dotnet/standard/serialization/system-text-json-converters-how-to?pivots=dotnet-5-0#support-round-trip-for-stackt.

Further notes:

• Carefully tried to extract common serialization/deserialization of JsonNet and System.Text.Json in a common project "UnitsNet.Serialization"
• UnitsNetIComparableJsonConverter is still missing -> time is running out...

Hope it works and helps :-)

[chucker]

(Haven't tried this yet, but thanks for giving it a shot!)

[angularsen]

FYI, #972 was merged.

Also, there was some discussion that reveals our current JSON schema is maybe not optimal.
ValueType and ValueString properties are likely not necessary in order to preserve decimal precision:
#972 (comment)

[dmytro-gokun]

@angularsen Is there any ETA on this? Maybe some help is required? We miss this feature a lot, it's the only thing that holds us back from migrating a big project to System.Text.Json :)

[angularsen]

@dmytro-gokun
ETA is whenever someone implements it 😄

If you want to help out, then great! I am not actively working on it myself, but @lipchev has done quite a bit of work on json lately.

Some relevant background:

#972
#985
#990

In particular, we see that maybe the current JSON schema can be simplified a bit, removing fields ValueString and ValueType that were originally added to support decimal.

@lipchev Do you plan to attack system.text.json anytime soon?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[maxreb]

I can see that its quite hard to find a efficient way to make Units.NET work with STJ, but wouldn't it for now be an option to just use the ToString and Parse methods so we have something which works with STJ? For every IQuantity we would need something like this:

public class LevelConverter : JsonConverter<Length>
{
	public override Length Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options) 
		=> Length.Parse(reader.GetString());
	public override void Write(Utf8JsonWriter writer, Length value, JsonSerializerOptions options) 
		=> writer.WriteStringValue(value.ToString());
}

and then above every IQuantity struct this line:

[JsonConverter(typeof(JsonConverter<Length>))]

As is said, I get it that the Parse method is not that efficient and on the long run we may should find another way, but this will at least make Units.NET work with STJ.

I would implement this, if you agree.

[maxreb]

Okay I found another solution how this will work with STJ. Install NuGet package ZCS.DataContractResolver and then replace the default TypeInfoResolver with the DataContractResolver. JST is now using the DataContracts:

//LevelSensorData is a class which implements Units.NET quantities
var opt = new JsonSerializerOptions()
{
	TypeInfoResolver = System.Text.Json.Serialization.Metadata.DataContractResolver.Default,
	//This line is optional, will convert the enums to string (so it will show "Millimeter" instead of "26")
	Converters = { new JsonStringEnumConverter() }
};
var str = JsonSerializer.Serialize(originalObject, opt);
var obj = JsonSerializer.Deserialize<LevelSensorData>(str, opt);

[angularsen]

Thanks for sharing @maxreb . Yes, DataContract should be one way to achieve this.

Another option is to implement custom converters, as this PR originally tried to. I believe that gives more control on the serialized format, but maybe data contract approach works well enough already.