location field: expose record type and id from geocode response in the onLayerSelected callback

[fpurcell]

See #13

Would like calling app to have access to data from the geocoder beyond name and coordinate. In Pelias there are 2 properties that carry needed information. The 'layers' property describes what type of record (e.g., a stop vs. an address vs. a venue, etc..). The 'id' property, for certain records, contains valuable information, like stop_id and agency_id (for layers=stops). Eventually there will be a 'routes' layer, which will contain a route_id, etc... The use of those 2 properties (type and id) might work well, since all records in Pelias have those fields, plus guessing other geocoders have similar values (e.g., should make things universal). That said, open to suggestions on other solutions and ideas to communicate needed information back to the calling app.

[randolphjones]

In the same vein, we noticed that the custom stop icon is not shown next to geocoder results on the stops layer. We'd like to be able to change the icon in accordance with the mocks we're working towards. One pattern that worked well for us with this last revision is the way the new LocationIconComponent is implemented. We created a dynamic icon component like this and supplied it its reference to the prop (see code below).

With this request I also understand the possible risk of tightly coupling your component to specific geocoder layers (which is something I assume you don't want) so it may require a slightly different implementation than LocationIconComponent? If that's the case then I think that's something we can overcome with a little more consideration. Please feel free to reach out if you would like to hash out the possibilities together.

Here's that dynamic icon component we provided to LocationIconComponent prop and it worked out very well for us (we were then able to re-use this component elsewhere in our app). We could create a dynamic icon that is keyed on geocoder layers.

/* eslint-disable react/jsx-props-no-spreading */
import React from 'react';
import PropTypes from 'prop-types';
import * as Styled from './styled';

const LocationTypeIcon = ({ locationType, ...props }) => {
  return {
    to: <Styled.DestinationIcon {...props} />,
    from: <Styled.OriginIcon {...props} />
  }[locationType];
};

LocationTypeIcon.propTypes = {
  locationType: PropTypes.oneOf(['to', 'from'])
};

LocationTypeIcon.defaultProps = {
  locationType: 'from'
};

export default LocationTypeIcon;

[evansiroky]

@fpurcell, I think what may be best is to pass through the raw geocode result data that applications can then parse.

@randolphjones there is already a slot for a custom icon for a stop icon. It is the stopOptionIcon property of the LocationField. You can see an example of the use of this custom icon in the story titled LocationField with in mobile context with custom icons. On that note, I'll correct the grammar of that story with this upcoming geocoder fix.

[randolphjones]

@evansiroky Thanks for the quick turn on that. I think we can work with the geocoder result. Appreciate you adding that. In regards to the icon. This is the design that we're working from for displaying geocoder results.

When I provide a React component to the stopOptionIcon prop, it doesn't display a different icon for geocoder results from the stop layer.
Here's an example of how I'm using that prop. As I understand it, it takes a node, correct?

          stopOptionIcon={<Styled.ButtonListIcon type="stop" />}

[evansiroky]

Oh, wait that stopOptionIcon only applies to nearby stops if you're including those from a nearby stops search. Try using GeocodedOptionIconComponent instead which also has a storybook example.

[randolphjones]

Thanks for the extra guidance @evansiroky I now see the feature prop that is expected on the component in that slot. Thanks for documenting that. Looks like the object has what we need to get the functionality we want. 👍

If I run into any other issues I'll let you know. Thanks again.