Incorrect Serialization of Enums about blazorgooglemaps

[valentasm1]

control is not positioned as TOP_LEFT but as BOTTOM_CENTER. this is different bug. Not related to serialization. Solved with #281

[cruiserkernan]

I believe it is another bug. Upon running the Blazor Server Demo and examining the MapLegendPage, I observed that its intended position, TOP_LEFT, is not reflected in the actual placement; it appears at BOTTOM_CENTER instead. During debugging, I noticed that the addControl method in the objectManager is receiving "topLeft" as the enum value. However, this doesn't seem to match any case in the switch statement, causing it to revert to the default case of BOTTOM_CENTER.

I initially noticed this in my current application when trying to position the control on RIGHT_CENTER.

using System.Threading.Tasks;
using GoogleMapsComponents;
using GoogleMapsComponents.Maps;
using Microsoft.AspNetCore.Components;
using Microsoft.JSInterop;

namespace ServerSideDemo.Pages;

public partial class MapLegendPage
{
    private GoogleMap map1;

    private MapOptions mapOptions;

    [Inject] private IJSRuntime jsRuntime { get; set; }

    protected ElementReference legendReference { get; set; }

    protected override void OnInitialized()
    {
        mapOptions = new MapOptions()
        {
            Zoom = 13,
            Center = new LatLngLiteral()
            {
                Lat = 13.505892,
                Lng = 100.8162
            },
            MapTypeId = MapTypeId.Roadmap
        };
    }

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            await jsRuntime.InvokeAsync<object>("initMapLegend");
        }
    }

    private async Task AfterMapInit()
    {
        await map1.InteropObject.AddControl(ControlPosition.TopLeft, legendReference);
    }
}

[valentasm1]

Please register new issue then. One bug one issue.

[cruiserkernan]

I can do that, I just thought that since it was a caused by the serialization it was one bigger issue, that control position was just one case where I noticed it. But I understand that it might be a separate thing and could be fixed with less of a code change.
I will create a issue for only the control position and and a pull request only for that.

[valentasm1]

No need PR. Just sample of code how it should is enough since change is very small

[valentasm1]

I merger PR. It dont work. I tried for 30min and give up. Reverted.
If you do functionality. Startup server demo and try markers diff func, drawing polygons, polylines. Maybe smth else.
I am a bit disappointed.

[cruiserkernan]

Sry my bad, I should have tested it more. I will update the code so that it works and thoroughly test it.

[Enritski]

I've been digging into this, and experimenting with a different custom serializer for enums.
I've come to the conclusion that a big part of the problem is due to the use of discriminated unions (OneOf) for various properties. If a type has a property that uses OneOf, the OneOfConverterFactory is used to serialize that property and does so by using the default serializer for whichever of the underlying types is being used. So, for example, in the case of the Symbol class, the Path property is a discriminated union: OneOf<SymbolPath, string>. The SymbolPath type is an enum and will serialize properly using the custom serializer (e.g., JsonStringEnumConverterEx), but not when it is part of a OneOf as is the case here.
I experimented with making the Path property just a simple SymbolPath instead of OneOf<SymbolPath, string> and that worked.
I've been trying to work out how to have the OneOfConverterFactory use the appropriate serializer for each of the possible types in the discriminated union, but haven't got there yet.
I just thought I'd add this comment here in case anyone else has an idea how to achieve this.

[valentasm1]

Sharing knowledge is always great. Thank you.