Use of queryRenderedFeatures for hover/click events etc. - possible to expose?

[cammanderson]

Hi Guys,

While the current implementation wrappers some of the interactions of 'onHoverFeatures' and 'onClickFeatures' as prop functions as convenience and to handle encapsulation around access to map, it won't be able to support the types of interactions that mapbox provides effectively.

Currently, in recent commits, there hit box for clicks has increased from '5' to '15', a hardcoded value to determine the bounding box to pass to 'queryRenderedFeatures'.

The problem is that the query rendered features function is a very powerful part of the mapbox-gl-js API, and largely the gateway to accessing features of the GIS platform. You may want to identify features that are currently drawn on the screen, or based on specifying a limited set of target layers.

Is there an effective way of exposing functions of the API that are not mutators that allow more leveraging of the mapbox API? Could it be possible that some of the functions of the API not affecting mapbox state can be exposed?

Would it be possible to expose wrapper functions of the component (e.g. provide a component ref and access this.refs.etc) to expose some API? Maybe like this.refs.map.queryRenderedFeatures()? It could be available in addition to the current supported API of the component props?

In combination with exposing some of the standard map event behaviour, it could provide a way to be able to interact with the map more effectively and open up easier ways to access the features out of the GIS component of mapbox.

Cheers
Cam

[cammanderson]

Hi Guys,

Just adding to the use case for this one. We've been optimising our maps and finding that the current 'onHoverFeatures' props function encapsulation choice does cause some limitations;

• Ability to use mapbox "layers" and "filter" to target only hover on certain map layers or where properties match criteria at the point of query
• Ability to control the hit area / size for the interaction (as per above discussion)
• Ability to throttle querying of features - being fired all the time on mouse move

With larger data sets the hover implementation can be too greedy and fired many times. We can limit once the features are passed to us via react-map-gl, but this doesn't necessarily improve the performance. If we can control the layers, filter and be able to handle our own throttling/spec around calling the mapbox GL standard/document API we can leverage more of the interactive nature of the maps.

I realise that using the refs in the above example is not ideal. Maybe someone could propose a way to expose the queryRenderedFeatures/querySourceFeatures published API methods without revealing the rest of the API effectively?

BTW, loving react-map-gl. It's great to work with. 👍

Thanks
Cameron

[cammanderson]

Sorry, just noting down a further suggestion, maybe the API method could be exposed using a child component context? e.g. getChildContext returning the exposed API methods? Otherwise potentially a HOC wrap. Might investigate that as a prop. :-)

[abmai]

hey @cammanderson did you guys do anymore explorations on this front?

[cammanderson]

Hi Guys,

I decided to take an alternative approach and implemented my changes in a new project. I did this to support all mapbox events and API, implements diffStyles, %/vw support etc, and a few outstanding feature requests. I also wanted to have high code coverage at 95% etc. addressing some of the things that I wanted to see happen.

If you are interested you can look at react-map-gl-alt project. I have documented a lot in the README.md to discuss where this project has differed and offers other features. It maintains the same exposed props and behaviour of this component contract, so it should support deck.gl, overlays etc. and virtually drop in place. I took an alternative approach to handling the viewport (still offers onChangeViewport etc) but I wanted to leverage the natural viewport controls that have been optimised by mapbox gl js for improved performance.

Specifically to addressing this issue, I decided to create a read-only map interface/facade (implementing all API of mapbox) through the context and events. It also is provided as a reference through the onChangeViewport event. I also decided to introduce a new MapEvents component that allows you to register any mapbox GL JS events at any child level (e.g. onMove, onMouseMove, onTouch, onDblClick, onLoad, onRender etc) which benefits from having access to the map API facade, which also in turn makes it convenience to be able to interact with the component.

Anyway, what started out as trying to think about ways to help make some PR's across here just made me reconsider an alternative implementation. It felt like to support some of this would be some pretty significant code contributions that I thought may not please the community with radical changes that are sure to come under some inflammatory comments.

Hopefully it helps provide some alternative ideas.

Cheers
Cam

[howtimeflies0]

Even though the original op has implemented his own "react-map-gl", we should still implement this as we discussed last week in the event handling discussion.

[abmai]

queryRenderedFeatures is exposed in v3. We'll definitely take a look at react-map-gl-alt too and see if there are possible collaborations down the road!

[maxwell-oroark]

Has this been implemented in react-map-gl? Do you have an approach similar to @cammanderson where the e.target argument fired by the hover/move/click events exposes access to the queryRenderedFeatures method? I'm a little confused on the outcome when following the thread 🙂

[Pessimistress]

@maxwell-oroark this thread is 3 years old and the API has changed a lot since then. Please check the latest documentation and open a new issue if you have questions.