Attributes update implementation, testing, and documentation #170
Conversation
| @@ -124,7 +118,7 @@ public bool Equals(Graphic? other) | |||
| return (other?.Id == Id) || | |||
| (other is not null && | |||
| (other.Geometry?.Equals(Geometry) == true) && | |||
| (other.Attributes?.Equals(Attributes) == true)); | |||
There was a problem hiding this comment.
I guess there are always attributes in graphic layers?
There was a problem hiding this comment.
Well, no, but the ? means this would not equal true if other.Attributes returns null.
| { | ||
| if (kvp.Value is JsonElement jsonElement) | ||
| { | ||
| object? typedValue = jsonElement.ValueKind switch |
There was a problem hiding this comment.
had to do some research on Valuekind (https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonelement.valuekind?view=net-7.0)
So this is what sets up the "conversion" of the attribute dictionary to allow the change comparison to occur.
There was a problem hiding this comment.
This is kludgy but yes, we're basically force-checking the type from JSON to C#.
| public object this[string key] => _backingDictionary[key]; | ||
| } | ||
|
|
||
| [ProtoContract(Name = "Attribute")] |
There was a problem hiding this comment.
Had to do some research on protobuf to get a little better understanding. Is speed the primary reason for serializing with protobuf in this situation?
There was a problem hiding this comment.
Yes, if you look at the protobuf serialization, you get highly-compressed data, where each class/property name is replaced by a number based on the position. This means less data per graphic, which equals to faster transfer when you have a large set.
Closes #168
Attributes now are a new
AttributesDictionarytype. I avoided a breaking change by adding an implicit conversion operator so users could still provide a plainDictionary<string, object>to the attributes parameter. However, they would need to get the strongly typed dictionary to call the new async methods for updating attributes.I actually did set up the blazor binding to actually update the attributes on next render if the parameter dictionary is altered. This is accomplished by overriding
SetParametersAsync. I think this is a pattern that might work to also support changing for example the Lat/Long of an extent after a user drags the view, which before I thought was impossible. You would have to store the previously-entered values, separate from values being tracked by user manipulation.Anyway, back to attributes, I'm not sure whether I should be marking/warning that providing
Dictionary<string, object>is deprecated, or if we should just keep supporting this as a convenience. The one thing that would not work is in C#, after render, to call_graphic.Attributes = new Dictionary<string, object>.... This would never update, unless you manually also called so makes me think we should keep the warnings.