Open miguelhasse opened 2 years ago
I agree with you, this is something I have on my roadmap. This will require some rework on how the library is built, but I have already done an analysis of what needs to be done to achieve this.
This will require a new major version of the library, as this will bring at least one breaking change, as the map won't be accessible like it is today from the Map service.
As already mentioned in other issues, I currently have issues finding time to work on this library, so a lot of things are in stand-by right now. Due to this and the relative complexity of the changes, this is not something I can release alone in the short term.
I'll still keep this issue open and will let you know when any progress is made
Any updates on supporting this use case? I need to be able to support maps that use a different client Id within the same application instance so cannot use the current method of registration and configuration.
I'm sorry, I currently have no time to work on this library (or on any other project for what it's worth). I'll try to take a look at it beginning of next year.
That's okay @arnaudleclerc. FYI, I'm working on some custom changes in a local fork for now. In short, I no longer register the configuration options and only register scoped implementations. Also modified the razor component to not inject the options and accept configuration via a parameter instead. Experimenting the impact of the changes but so far seems okay.
@markphillips100 are you using Blazor's JavaScript Isolation?
I went with the map dictionary approach. It's not something I can do a pr for though as I also integrated mapboxdraw for my own needs, and my time is also tight
The way the azmaps.Map instance is internally stored doesn't allow for the library to support multiple AzureMap components. Instead of a single static instance inside the Core class, a dictionary holding component Ids and azmaps.Map instances should be used.