Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

include matching text in suggestions #153

Closed
andrewharvey opened this issue May 29, 2018 · 3 comments
Closed

include matching text in suggestions #153

andrewharvey opened this issue May 29, 2018 · 3 comments
Milestone

Comments

@andrewharvey
Copy link
Collaborator

Currently results will be displayed in whichever language was set in the options.

{ language: 'en', country: 'au' }

en_au

{ language: 'zh', country: 'au' }

zh_au

To get results displayed in one language, but still display the matching text if the query was in another language you need to do something like:

geocoder._typeahead.getItemValue = function (item) {
    if (item.matching_text) { // matching text is the text the query matched, so will be in the same language that the user queried in
        return item.matching_text + ' (' + item.place_name + ')';
    } else {
        return item.place_name;
    }
};

zh_au_matching_text

That feels a bit hacky though, I'm thinking if doing this be better supported without overwriting the internal _typeahead.getItemValue method, or even if this should become the default?

@scottsfarley93
Copy link

What about adding a constructor option to provide a function that allows implementation-specific customization over how the results are displayed?

Something like:

var geocoder = new MapboxGeocoder({ 
    accessToken: mapboxgl.accessToken,
    render: function(result){
        return item.matching_text + ' (' + item.place_name + ')'
   }
})

We could provide a sensible default (either keep it the same as it is now (use place_name) or use a function that renders the matching text in the dropdown), but provide the ability to override with something different if desired.

@andrewharvey
Copy link
Collaborator Author

👍 I think that's the way to go.

Rethinking about this, the current defaults are probably good as they are.

@scottsfarley93
Copy link

The ability to do this was introduced in #208. While the defaults have not changed, once version 4 is released, additional fields can be accessed via the render function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants