[SignalR] Add convenient POJOs.

[Y-Sindo]

Issue describing the changes in this PR

resolves partially #771

Pull request checklist

• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• I have added all required tests (Unit tests, E2E tests)
  I have tested it manually, but I don't know how to write unit tests or E2E tests for it.

[kshyju]

Question: Wonder how it will work if customer chooses to override JSON serializer to be JSON.NET.

[Y-Sindo]

I have tried to change the JSON serializer to Newtonsoft.JSON as the code below and it still works. Maybe the conversion for bindings is not controlled by users. I am not sure about this, maybe we need a dotnet worker expert to confirm this.

    class Program
    {
        static async Task Main(string[] args)
        {
            var host = new HostBuilder()
                .ConfigureFunctionsWorkerDefaults(o =>
                {
                    var settings = NewtonsoftJsonObjectSerializer.CreateJsonSerializerSettings();
                    settings.ContractResolver = new CamelCasePropertyNamesContractResolver();
                    settings.NullValueHandling = NullValueHandling.Ignore;
                    o.Serializer = new NewtonsoftJsonObjectSerializer(settings);
                })
                .Build();
            await host.RunAsync();

[Y-Sindo]

I have found that NewtonsoftJsonObjectSerializer still works because Newtonsoft.Json has built-in support for enum->string.

[Y-Sindo]

Is there any way to avoid customers changing the serialization and deserialization of some field of my POJO? For example, I want to make the enum SignalRGroupAction serialized to string instead of number no matter how customers set their object serializer. But for the Arguments field in SignalRInvocationContext, SignalRMessageAction, I want to let the customers to control the serialization/deserialization.
@fabiocav

I think what we need can be concluded to have independent JSON serialization/deserialization for these POJO so that I can control which fields should be serialized/deserialized with WorkerOptions.Serializaer and which should not.

[kshyju]

This is not a blocker to merge this change. Something we should validate though.

[fabiocav]

To add context. No, today, the configured serializer will be used by default. We're adding features that will give binding authors better control of this, but in the meantime, I agree with @kshyju , we don't need to block, but it might be something worth documenting.

[kshyju]

will be joined by comma.

Or should we consider using <string,stringvalues> as the type?

[Y-Sindo]

I think it is a good idea, but deserialization is still a problem. If we customize the deserialization, how to avoid the customization changed by customers.

[fabiocav]

Would be nice (not critical) to match how HttpRequestData exposes this information for consistency, but that uses HttpHeadersCollection

[Y-Sindo]

HttpHeadersCollection is in a .NET 5 project, and cannot be referenced by .NET Standard 2.0 project.

[kshyju]

We should also consider adding sample usage of this types in the extension samples.

[Y-Sindo]

Currently the extension samples use package reference, so we cannot add new usages to the samples until they are released.

[fabiocav]

Would be nice (not critical) to match how HttpRequestData exposes this information for consistency, but that uses HttpHeadersCollection

[Y-Sindo]

I think the PR is ready to be merged now. Thanks!

[kshyju]

I think the PR is ready to be merged now. Thanks!

Feel free to merge.

[Y-Sindo]

I think the PR is ready to be merged now. Thanks!

Feel free to merge.

I don't have the write access to merge currently.

[kshyju]

/check-enforcer evaluate