Customize serialization for IJSRuntime.InvokeAsync

[Joelius300]

Before I write anything else.. I have already created an issue a while ago with pretty much the same problem (which I will copy to here as well) but with a solution that didn't really make sense. I now have a concrete idea/solution which is a lot better than what I suggested in my previous request.

Issue (similar to old issue)

Because IJSRuntime.InvokeAsync now uses System.Text.Json instead of Newtonsoft.Json (preview6+) the custom serialization I implemented with Newtonsoft.Json doesn't work anymore. Specifically null values aren't ignored anymore.
Even though it says in the issue I linked..

Users may use a JSON serializer of their choice.

.. the IJSRuntime doesn't use Newtonsoft.Json if you add Newtonsoft.Json in the ConfigureServices method using AddNewtonsoftJson on the IMvcBuilder.

I have already made a comment in the discussion for this issue describing the issue and what I already tried (back then I didn't know this wasn't the default behaviour). In this comment I also link to my SO question where you can find further information on the attempts I've made (same as before, I assumed this wasn't default behaviour).

These issues and questions might mention the need to be able to use Newtonsoft.Json with IJSRuntime. This is not anymore the case as I want to migrate all the custom serialization to System.Text.Json anyway as soon as the API allows all the desired customizations I require.

Request / Idea

Now instead of allowing users to customize what serializer is used (replace System.Text.Json.JsonSerializer), I only want to talk about the JsonSerializerOptions (customize System.Text.Json.JsonSerializer).
I have examined the source code for IJSRuntime and the corresponding implementation(s). From that I have found out that the base class of all implementations (JSRuntimeBase) uses the class JsonSerializerOptionsProvider (see Line 67) which always holds the same JsonSerializerOptions. This can't be influenced by a user of the API.

Now how would you allow the user to customize those JsonSerializerOptions?
It seems like it would be as easy adding another optional parameter to the InvokeAsync methods of type JsonSerializerOptions with a default value of null. For documentation purposes it might be a good idea to make JsonSerializerOptionsProvider public instead of internal so you could say something along the lines of:

if not provided <see cref="JsonSerializerOptionsProvider.DefaultOptions"> will be used.

This seems to already be quite detailed and is of course not up to me to decide, I just wanted to bring up the idea.

I realize that my old request was a bit too broad as well as probably too expensive to implement currently. This however seems much more lightweight and with a clear solution. I think it would be a great addition to this API as it can be a great advantage to be able to customize how the IJSRuntime serializes your arguments.
The biggest advantage for me (and probably one of the biggest use cases overall) would be that I could set IgnoreNullValues to true which is of course not the default value.

[mkArtakMSFT]

Thanks for contacting us, @Joelius300.
Why do you want null-values ignored?
In general, we don't plan to make the serialization customizable in Blazor, however per-type customizations are allowed today using Sytem.Text.Json. Here is a sample: https://github.com/aspnet/AspNetCore/blob/master/src/Components/Components/src/ElementReference.cs#L15

[Joelius300]

I need the null values ignored because I'm writing a Chart.js port for blazor (github-repo) and Chart.js has issues if a value is null instead of undefined. Here's a comment from an issue of a similar project where it is also mentioned that null values cause trouble for Chart.Js.
Btw here is the issue for this problem in my repo.
The current workaround uses the following steps (the code is in this file):

1. Serialize with json.net with options to ignore all null values (this could also be done with System.Text.Json)
2. Deserialize with json.net to an ExpandoObject which now of course doesn't have the properties that were null anymore. As far as I know System.Text.Json currently doesn't support deserializing to ExpandoObject so I have to use json.net for that.
3. Restore important property-values that were lost during serialization. This includes multiple DotNetObjectRefs that are of course really important for the whole thing to work correctly.
4. Turn the ExpandoObject into a Dictionary<string, object> recursively since System.Text.Json doesn't support serializing ExpandoObject.
5. Invoke the javascript function with the Dictionary<string, object> as parameter using IJSRuntime.InvokeAsync. All the null properties of the initial object are of course not present in this dictionary and thus will be interpreted as undefined rather than null, making the whole interop work at all.

If I was able to use JsonSerializerOptions with IgnoreNullValues = true on IJSRuntime.InvokeAsync, I could directly invoke the javascript with the original object as parameter. This would allow me to not only remove all the dependencies to json.net but also to remove 4 out of 5 steps, making this process much simpler and less ugly (I don't like ExpandoObject).

Hope this helps :)

Ps. Thanks for the sample for how to use a custom converter with System.Text.Json, I was not able to find a good one myself.

[Joelius300]

Are there any updates on this?
Do you still require more information or am I just too impatient? :)
@mkArtakMSFT

[mkArtakMSFT]

@Joelius300, you should be able to write a JSON converter and apply to your model types to do this for you. Hope this helps: https://docs.microsoft.com/en-us/dotnet/api/system.text.json.serialization.jsonconverter-1?view=netcore-3.0

[Joelius300]

I need this for every class in the model (it should be global) and the model is a huge with tons of nested and derived classes. It's a port for chart.js which means I have to model these huge json objects that can be used to configure a chart. If I were to create a custom converter for every single one, it would not only take a huge amount of time but also flood the project with converters.
I might be able to create a single converter with a factory used for every class in the tree but since I cannot add them to the Converters used by IJSRuntime (options are not exposed), I will have to add a JsonConverterAttribute to every single model-class. Not only will almost every class in my project have this attribute, it will also create colisions with existing converters (there are a lot of those as well) because you can only define one custom converter (makes sense).

Even if I managed to get this to work with all these converter-attributes (which I honestly doubt), after fixing all the colisions etc, it would be kind of a bodge, and not a particularly good looking one. From looking at the source of JSRuntime, it's clear that now you're not using the provider anymore. Instead you're creating the options directly in the constructor. You then store it in a protected internal property which makes it inaccessible outside the assembly unless you decide to fully implement your own js-runtime (can't derive from the ones used, they're internal).

I have already used JsonConverter and JsonConverterFactory but I'm not quite sure what you expect me to do. Adding all of these attributes looks and feels horrible plus it creates colisions. Do you have a concrete idea how to achieve this? I believe that you won't ever consider making the serializer-options accessable, correct?

[danroth27]

Clearing the milestone so we can discuss if we want to enable support for customing serialization options per JS invocation.