The TagComponent API currently only contains a single method for updating the set of tags, setTags. In many scenarios, like when adding a single new tag, this is not very efficient because all tags are removed and recreated. A better API would be similar to the one of the MarkerComponent with the following methods:
add(tags: Tag[]): void
has(id: string): boolean
get(id: string): Tag
getAll(): Tag[]
getTagIdAt(pixelPoint: number[]): string
remove(ids: string[]): void
removeAll(): void
We should also remove the tags$ observable from. If found relevant it should be replaced by an event without event data. The geometryCreated$ observable should be replaced by an event. The internal implementation could be simplified with this API.
Also, the TagComponent has two methods related to starting creation of new tags and stopping creation of new tags. This could instead be refactored to a single method that sets the mode of the TagComponent. The modes would be something like:
Static
CreatePoint
CreateRect
CreatePolygon
Refactoring according to this issue would require breaking changes to the TagComponent API. It has not been part of the publicly documented API up until now but the plan is to make it a part as well as creating tag examples for the upcoming release.
Question is whether this would require bumping the version to 3.x or not.
The
TagComponentAPI currently only contains a single method for updating the set of tags,setTags. In many scenarios, like when adding a single new tag, this is not very efficient because all tags are removed and recreated. A better API would be similar to the one of theMarkerComponentwith the following methods:We should also remove the
tags$observable from. If found relevant it should be replaced by an event without event data. ThegeometryCreated$observable should be replaced by an event. The internal implementation could be simplified with this API.Also, the
TagComponenthas two methods related to starting creation of new tags and stopping creation of new tags. This could instead be refactored to a single method that sets themodeof theTagComponent. The modes would be something like:Refactoring according to this issue would require breaking changes to the
TagComponentAPI. It has not been part of the publicly documented API up until now but the plan is to make it a part as well as creating tag examples for the upcoming release.Question is whether this would require bumping the version to 3.x or not.