feat(core)!: rework markers for cluster usage - #921
Open
oeninghe-dataport wants to merge 1 commit into
Open
Conversation
The current implementation used `selectedBaseFeature` to keep track of which feature to select when zooming in and out. This did not work properly, and is not intuitive either. Therefore, we split the (meant) hovered or selected feature and its (rendered) hovered or selected cluster. If the layer does not use clustering, cluster and feature are equivalent. This has the additional advantage that `isSelectable` does no longer consider the cluster, but an actual feature, such that the implementation is automatically cluster-agnostical now. This allows the GFI plugin to adapt this new API. When `bindWithCoreHoverSelect` is used now, the synchronization with the markers is now truly bi-directional and wrapped in a single, easy-to-understand composable. To allow the synchronization from the details view back to the marker store, the selected feature is moved to the GFI main store as a shared state between list view and details view. One could possibly split these changes into two or three (still atomical) commits. However, the changes only make sense in the context of this refactoring idea, and are therefore combined to one commit on purpose.
oeninghe-dataport
requested review from
czirkelbach,
dopenguin and
raschju
as code owners
August 7, 2026 16:05
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The current implementation used
selectedBaseFeatureto keep track of which feature to select when zooming in and out. This did not work properly, and is not intuitive either.Therefore, we split the (meant) hovered or selected feature and its (rendered) hovered or selected cluster. If the layer does not use clustering, cluster and feature are equivalent.
This has the additional advantage that
isSelectabledoes no longer consider the cluster, but an actual feature, such that the implementation is automatically cluster-agnostical now.This allows the GFI plugin to adapt this new API. When
bindWithCoreHoverSelectis used now, the synchronization with the markers is now truly bi-directional and wrapped in a single, easy-to-understand composable. To allow the synchronization from the details view back to the marker store, the selected feature is moved to the GFI main store as a shared state between list view and details view.One could possibly split these changes into two or three (still atomical) commits. However, the changes only make sense in the context of this refactoring idea, and are therefore combined to one commit on purpose.
This is merged onto the GFI migration, however, as the changes have a lot of changed lines and touch the core significantly, I propose to discuss this changes as a separate PR for clarity.
When this is accepted, it will (hopefully) solve a few threads in #447