Description
A new component shall be introduced that handles opening a single plugin, pretty much as the IconMenu does, that is, including tooltip provision and using its icon. That component's WIP name is "PolarOpenButton". However, we found "PolarMaybeOpenButtonOrContentDirectly" could be deemed more fit; since that name isn't quite the catch either, there's some intense thinking required on this part.
The component shall then be used in plugins that may potentially "open" something; i.e., single-button elements like GeoLocation do not need this.
This wrapper may then be used for various plugins like LayerChooser, Filter, Attributions, and others that "open" a thing. It can be used as an alternative to the IconMenu for clients where this behaviour is deemed fit/neccessary, and shall be active during renderType: 'independent'. While I really like stuffing everything to the IconMenu, such cases may occur for e.g. Attributions on a regular basis, or when any action has particular prevalence for a client's function.
Since renderType is touched, please mind this:
renderType has three possible values, iconMenu, independent, and, only for Attributions so far, footer. It may prove worthy to, for this issue, change those values to iconMenu, independent, and always-open, where iconMenu behaves as previously, independent makes use of the new-to-write PolarOpenButton, and always-open just renders the contents that the button would open without such a wrapper. With such a solution, the decision whether the PolarOpenButton renders should be delegated to the very same to prevent code duplication amongst plugins. footer as value in Attributions wasn't semantic anyway as this footer could be placed e.g. layoutTag: 'MIDDLE_MIDDLE'.
Affected areas
In the components folder, a new component is to be written.
The PlaceablePluginOptions type has to be partially refactored, where a new type also providing always-open as renderType option is required across fitting plugins.
| Plugin name |
Should it use PolarOpenButton? |
| addressSearch |
❌ No, this is always visible. |
| attributions |
⭕ Yes, it opens attributions. |
| export |
⭕ Yes, it may open multiple buttons. |
| filter |
⭕ Yes, it may open various forms. |
| footer |
❌ No, this lives by itself. |
| fullscreen |
❌ No, this doesn't open anything. |
| geoLocation |
❌ No, this doesn't open anything. |
| gfi |
⭕ Yes, this can open both a feature list and features. Please mind that some pin selections may require to open this. This has to be supported for the new mode, too. |
| iconMenu |
❌ No, this is a separate solution. |
| initialView |
❌ No, this doesn't open anything. |
| layerChooser |
⭕ Yes, this opens forms. |
| loadingIndicator |
❌ No, this lives by itself. |
| pins |
❌ No, this has no UI. |
| pointerPosition |
❌ No, this is always open. |
| reverseGeocoder |
❌ No, this has no UI. |
| routing |
⭕ Yes, this opens forms and information. |
| scale |
❌ No, this is always open. |
| toast |
❌ No, this lives by itself. |
| zoom |
❌ No, this doesn't open anything. |
Out of scope
The IconMenu shall not be touched in the process, despite looking oddly fitting, unless you see a great chance to shorten duplicate code.
Description
A new component shall be introduced that handles opening a single plugin, pretty much as the IconMenu does, that is, including tooltip provision and using its icon. That component's WIP name is "PolarOpenButton". However, we found "PolarMaybeOpenButtonOrContentDirectly" could be deemed more fit; since that name isn't quite the catch either, there's some intense thinking required on this part.
The component shall then be used in plugins that may potentially "open" something; i.e., single-button elements like GeoLocation do not need this.
This wrapper may then be used for various plugins like LayerChooser, Filter, Attributions, and others that "open" a thing. It can be used as an alternative to the IconMenu for clients where this behaviour is deemed fit/neccessary, and shall be active during
renderType: 'independent'. While I really like stuffing everything to the IconMenu, such cases may occur for e.g. Attributions on a regular basis, or when any action has particular prevalence for a client's function.Since
renderTypeis touched, please mind this:renderTypehas three possible values,iconMenu,independent, and, only for Attributions so far,footer. It may prove worthy to, for this issue, change those values toiconMenu,independent, andalways-open, whereiconMenubehaves as previously,independentmakes use of the new-to-write PolarOpenButton, andalways-openjust renders the contents that the button would open without such a wrapper. With such a solution, the decision whether the PolarOpenButton renders should be delegated to the very same to prevent code duplication amongst plugins.footeras value in Attributions wasn't semantic anyway as thisfootercould be placed e.g.layoutTag: 'MIDDLE_MIDDLE'.Affected areas
In the
componentsfolder, a new component is to be written.The
PlaceablePluginOptionstype has to be partially refactored, where a new type also providingalways-openasrenderTypeoption is required across fitting plugins.Out of scope
The IconMenu shall not be touched in the process, despite looking oddly fitting, unless you see a great chance to shorten duplicate code.