Map - Decide on whether we are shipping a importable component or a pattern implementors may reference

[halocline]

Suggestion

As a dev team,

For consideration

• Where should Map live?

• Map and related components will live in a separate repository from grommet

• What is the contract HPE Design System is committing to?

• Committing to maintenance + support of an additional project which will be relied on by HPE teams

• Committing to fixes/enhancements/dependency upgrades/releases/etc.

• Keeping separate from grommet allows us to focus on the use cases from HPE

• Will allow lower maintenance vs trying to commit to and support mapping requests from the open-source community

• Keeps what we are shipping in grommet focused to base components -- limits additional dependencies/bundle size/etc and stays true to grommet's focus/strengths

• Will allow flexibility in the future to shift to other technologies if needed/desired

• What does the developer experience consuming Map look like?

• Implementation is fairly intuitive with passing children, using marker cluster

• To be revisited from implementation-side: The box rounding is built into the marker pin. Is there a way to be more flexible to allow different shapes? Applies to maintenance as well

• To be revisited from design-side: Adding extra text to individual marker, visually big

• To be discussed once we review our use case implementations

• What is the API like?

• Goal is to stick as closely to leaflet API as possible

• To discuss later: Need to assess areas where that is limiting/come up with shared understanding of when to extend props vs have the caller implement on their own (to consider is consistency across teams, eliminating one-offs)

• To discuss later: How much to rely on leaflet functionality vs react-leaflet?

• Is the HPE Design System staffed to support and commit to long term support?

• With the goal to keep the API as aligned with leaflet as possible/minimizing the complexity of props we extend/etc., it should be fairly stable to maintain. Primarily focused on keeping up to date on dependencies, etc.

• There are some unknowns with how teams will consume/where they will want to extend or take map features.

• What are contingency options should the team not have staffing to support?

• Leaflet is open-source and allows wide flexibility in the implementation. Callers should be able to implement their designs flexibly using Leaflet's API.

Map capabilities to consider in assessment

(may be revised to MVP-appropriate level)

Plot locations - (Jessica)

• Receive array of longitude-latitude coordinates and plot locations on map, displayed as individual location markers
• Receive locations as a GeoJSON object and plot individual locations on map.

PR: grommet/grommet-leaflet#5

Individual locations (Taylor)

• Display an individual location as a custom Grommet-based marker.
• Individual Grommet-based markers should be able to be customized based on status (good, warning, critical).

PR: grommet/grommet-leaflet#6

Location clusters (Taylor)

• Consolidate a group of locations and display as a custom Grommet-based "cluster marker."
• Grommet-based "cluster markers" should be able to be customized based on status (good, warning, critical).
• Grommet-based "cluster markers" should be able to display the number of individual locations contained in the cluster.
• Grommet-based "cluster markers" should be able to display a custom label in place number of locations.
• Grommet-based "cluster markers" should be able to display custom children.

PR: grommet/grommet-leaflet#7

Zoom - (Jessica)

• Display styled (+/-) zoom controls
• Display reset / "fit my data" zoom control
• Initialize zoom level at "fit my data" level

grommet/grommet-leaflet#9

Reveal additional location detail (Taylor)

• Markers (and Cluster Markers) should be able to reveal a "pop up" which can display any custom Grommet children.
• Allow interactive element such as an anchor allowing for navigation to an object's detail page or filtered data view. (Revisit with designers. It seems the intent is so have this appear on hover and therefor not include interactive elements in it)

PR: grommet/grommet-leaflet#10

Others

• List others as considered
• Add Google Maps assessment to mapping options comparison, add security considerations as a line item: https://www.figma.com/file/5wrkWT2NllOoInCWVHU4KY/Mapping-Options?type=whiteboard&node-id=0-1&t=sg1tbyOFxhOfKj4m-0

##Deliverables

• Map - RESEARCH SPIKE - Create proof of concepts for as many of the MVP features #3393 [time-boxed to 1 week, due at Show & Tell]
• Map - RESEARCH SPIKE - Compare and contrast map alternatives to LeafletJs #3394 [time-boxed to 1 week, due at Show & Tell]
• Recommendation on pattern vs. component.
• Draft API surface.
• Map - Confirm where the technical implementation of a map should live #3385
• Review changes to grommet-leaflet-core grommet-leaflet#24
• Assess scope, provide level of confidence delivering (need to discuss this more, likely after completing Review changes to grommet-leaflet-core grommet-leaflet#24)