FeatureState support for Layout
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 12.4k
- Forks
- 2.4k
- PR merge metrics
- No merged PRs in 30d
Description
## Motivation
Currently, the only "feature-state" properties are Paint. When working with interactivity on symbols, it doesn't give enough flexibility to work with complex sets of data and interactions without reverting to modifying the data source data. Currently the feature-state supports things such as halo and opacity for symbol.
Examples of wider feature state interactions and state include: hover, select, filter, relate, default icons, apply a collection of icons based on an application selection criteria. This ideally requires that the icon and visibility are dynamic based on application state.
I wish to propose consideration/discussion around the addition of "icon-image" (a layout property) to be able to access feature state, and then potentially expanding to "visibility".
Symbols are a core part of the application stylising. When we create interactions with the data, we use feature-state in order to be able to capture interaction with symbols. If we wish to create categorisation (such as assigning different symbols different icons given a different view of the data), or be able to toggle on groups of features that match criteria, the feature-state would be the place for us to be able to do this. We can quickly create properties in the feature-state (e.g. { selected: true }, { related: true } etc).
Currently, without access to the feature-state to modify visibility or icons, we must devise filter expressions that can eliminate the data (or show only what we need) into specific layers, which requires all filter criteria to be within the properties of the feature. If we need to interact to assign a different symbol, we either have to create a number of layers to match all the possible symbols we want to assign, or again modify the underlying data properties in order to read back.
Unfortunately, modifying the source data comes with a cost, and writing numerous layers also has a cost, and updating the filtering can be limiting if we have the complexity of the object in our application. Ideally, Feature State existed for faster state management of particular features.
We have worked around this in the past, but we are getting to a point where we are having to hide properties through opacity (not ideal) or have resorted to updating underlying data (to modify a symbol), but as you are filtering and moving through large collections of data we are getting slight unresponsive steps when we swap the data.
If we could control the icon-image and visibility with Feature State, we could quickly set symbol collections or change icons with ease.
### Implementation
Update the style specification to support feature-state.
If the feature state updates for a feature, it would cause a re-render/paint of that feature. We could limit the layout props so that we don't modify other behaviours, such as collision, spacing, etc on a feature by feature basis.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the style specification and the existing Paint feature-state support. Define how icon-image and visibility should consume feature state, including the proposed per-feature re-render behavior and the limits around collision and spacing; done means the specification and implementation support the agreed scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100