Review changes to grommet-leaflet-core

[taysea]

Based on our implementations of Aruba, Compute Ops, and GreenLake Cloud Platform, let's discuss:

• Any API surface changes we made that deviate from the native leaflet/react-leaflet API
• Implementation of "Pin" (with built in border-radius/rotation) -- is this too opinionated?
• From design side, individual pins with custom content (more than just status indicator)

[taysea]

We had this discussion on 7/31. The outcomes of the review were to:

• Remove icon, label props from Cluster. This supports desire to keep the initial API surface limited and only expand as use cases arise: Project cleanups to simplify API surface #30
• Ideate on way to allow caller to override default Popup pad: Complete action items from grommet-leaflet-core review #33
• Rename grommet-leaflet-core markers directory to layers, move everything in there. This is just a project structure cleanup but doesn't affect caller: Project cleanups to simplify API surface #30
• Use …rest on Marker instead of destructuring certain props. This supports the mentality to allow any native leaflet props to be passed through: Project cleanups to simplify API surface #30
• Assess screen reader behavior with Map and markers. Come up with best practices for what should be read out by a screen reader and determine if anything can be built into grommet-leaflet-core or have an example demonstrating best practice: Complete action items from grommet-leaflet-core review #33
• Think about how popup should be applied to an individual Marker. Child of marker popup is the native behavior, but that’s counter to the grommet pattern where children would alter the content within a Marker: Complete action items from grommet-leaflet-core review #33
• Simplify locations logic in Controls to accept GeoJSON or array of lat long: Project cleanups to simplify API surface #30
• Pull out zoom to bounds duration as const: Project cleanups to simplify API surface #30
• Remove GeoJSON from grommet-leaflet-core for now. This supports desire to keep what we commit to initially limited to use cases we have. We can support the desired use cases (and geojson data) without the GeoJSON component: Project cleanups to simplify API surface #30
• Cluster theming, specifications for kind + size overrides, think about how that gets built up: Complete action items from grommet-leaflet-core review #33
• Double check that zIndex in .css file is working for base theme + hpe theme: Complete action items from grommet-leaflet-core review #33

[taysea]

Closing this ticket. Have filed a new one which includes all of the open items listed above: #33