Closed TimPurdum closed 1 month ago
Questions above aside, these changes will make GeoBlazor work inline with the ArcGIS JS SDK, along with a few other options that you could use to manipulate the AttributesDictionary
server-side. I think that is a step in the right direction, it fixes the issue raised by an end user in Europe, and it should be merged.
After discussing with @AndersenBell, we came up with a better plan. In my changes, we now query once for the browser language in JsModuleManager
when the js modules are loaded. This is then referenced in AttributesDictionary
to deserialize, and we no longer need to add the culture to each attribute dictionary.
Closes #319
navigator.language
with graphic attributes indotNetBuilder.buildDotNetGraphic
CurrentCulture
.TestRunnerBase.razor
for synchronous testsThere is some question in my mind still if this is the "right" or "best" approach. The issue IMO stems from the following:
How these 3 pieces fit together, and how to know that we aren't breaking data in any one scenario (data from AGOL in culture A, data from GeoBlazor in culture B, etc.).
For example, if we pass data to ArcGIS JS layers in culture A from GeoBlazor, but the client is in culture B, when it returns to GB, it will have culture B tied to the data. Some of this stems from the fact that Blazor is both a server and client technology, often in the same application.