[API Proposal]: JsonSerializer.TryReadValue(ref Utf8JsonReader)

[davidfowl]

Today if the JSON passed into the JsonSerializer needs to be the fully formed, this means its basically impossible to let the caller handle buffering (which is unfortunate). This seems solvable if we add a TryReadValue which would return false if the Serializer failed to Read the full object from the Utf8JsonReader.

public static class JsonSerializer
{
    public static bool TryReadValue(ref Utf8JsonReader reader, Type returnType, out object value, JsonSerializerOptions options = null);
    public static bool TryReadValue<TValue>(ref Utf8JsonReader reader, out TValue value, JsonSerializerOptions options = null);
}

This currently wouldn't preserve the serializer state, but it would let the caller buffer an entire JSON payload from a Stream of bytes without a surrounding envelope.

[mqudsi]

I agree, this would make things easier.

this means its basically impossible to let the caller handle buffering (which is unfortunate)

I thought so too, but then I realized there was sufficient low-level state available to work around the limitations.

I actually just finished (technically it was at 3am, but who's keeping track? 😂) implementing a non-blocking, asynchronous Stream (or anything else, I guess) deserializer on top of the presently exposed System.Text.Json API surface. That was actually the easy part, the difficulty was in creating an async non-blocking equivalent to (yet better than!) the old Newtonsoft JsonTextReader. It wasn't fun (especially because Stream is ornery and ugly (why oh why can I not read from a Stream to a byte *?) and I need .NET Standard support, and System.IO.Pipelines doesn't help here at all in its latest non-preview state), but it's working with more-or-less zero copy and zero large-object allocations regardless of payload length while still allowing for caller-controlled buffering (and being called from an async context, no less).

There are some issues I ran into (which I've been filing along the way), but it's certainly doable!

[frankhaugen]

Would name this TryDeserialize()

And include a TrySerialize(), because suddenly you have something too complex or self recursive references that will cause a crash unless wrapped in try/catch. when creating a library you have no control over what is being serialized, it results in so many bug reports

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of the experimental issue cleanup initiative we are currently trialing in a limited number of areas. Please share any feedback you might have in the linked issue.

[davidfowl]

😢

[udlose]

Sad to see this being killed off