Option to JSON Serialize/Deserialize enums as string

[drkmn]

Please add the (optional) ability to serialize/deserialize Enum values to/from (camelCased) string rather than numeric value. This functionality is available in Json.NET as well.

Several API's expose fixed "choice" values as string-like enumerations and with the current functionality we would be forced to map such values to a string and roll our own post-deserialization parse logic.

[MihaMarkic]

A workaround would be to implement custom serialization/deserialization, see aspnet/Blazor#664.

[drkmn]

@MihaMarkic Sure that could work, but why not add some frequently used real-life scenario functionality to the built-in Json parser? I'm not advocating turning it into a full blown json.net clone, but having enum-to-string serialization (and ignoring null-value properties for that matter) seem like minor additions while preventing having to roll your own workarounds or having to include an alternative json library.

[MihaMarkic]

I'm not against it, just providing a workaround.

[SteveSandersonMS]

@drkmn Thanks for suggesting this. It's a very reasonable feature to request.

However, we're finding that we're getting a lot of requests for additional JSON features. Clearly it's a complex area. If we went ahead with these, we'd spend a large part of the Blazor team's limited resources building, testing, and maintaining a whole new JSON library and therefore wouldn't make so much progress on Blazor itself, which I think is what most of you really want us to do. Therefore it's better to avoid adding this, and other JSON features.

What we suggest instead is that for anything beyond the basic cases covered by the minimal built-in JSON utility, you should use one of the other .NET JSON libraries. If there are scenarios where you're unable to use a different .NET JSON library (e.g., because of build or runtime errors, or lack of API support for custom serialization), please let us know. I'm sure there are some limitations like that, and we are definitely interested in solving those to give you flexibility to pick the most suitable JSON library for your needs.

Hope that makes sense!

[drkmn]

I understand that it is a matter of resources and priorities and I indeed much prefer that the team focuses on the core Blazor functionality. The issue is that with the built-in HttpClient extension methods, Blazor currently takes a kind of opinionated stance on the suggested way of working with Json for service calls (namely using the internal Json functionality). My concern is that given this functionality is probably too limited to be of practical use in serious applications, thus in practice (almost) always requiring an external library to get the job done, making the built-in functionality practically superfluous.

Maybe putting the built-in Json extension methods in a different namespace (e.g. Microsoft.AspNetCore.Blazor.Json) might take away some of this confusion and will make it easier to apply alternative extension methods for working with Json

[Sire]

@SteveSandersonMS: What we suggest instead is that for anything beyond the basic cases covered by the minimal built-in JSON utility, you should use one of the other .NET JSON libraries.

Sounds good. Is there any easy way of switching to Json.NET (Newtonsoft)?