Add "Map#isMoving" method

[lucaswoj]

It is useful to know whether the map is currently moving (i.e. because of a flyTo call). This method would sit alongside Map#loaded (to be renamed to Map#isTilesLoaded?) as a guard against expensive operations during times of rapid map change

map.on('render', function() {
    if (!map.isMoving() && map.isTilesLoaded()) {
        map.queryRenderedFeatures(...)
    }
});

cc @peterqliu

[lucaswoj]

I think this is a solid alternate solution for #2471

[peterqliu]

👍 I think this would be useful for expensive operations that need to happen regularly ("keep doing this, unless the map is moving").

However, it shouldn't replace #2471 altogether. For occasional operations, it's easier to reason about what's going on via event callbacks (moveend, dataend, renderstable, etc), rather than constantly checking the map state before executing something.

[averas]

There is currently issues with Mapbox GL JS Draw in regards to adding/removing draw in a controlled fashion (mapbox/mapbox-gl-draw#572). This is in part related to that adding Draw currently depends on Map#loaded returning true, which during long transitions can take a while. If draw is removed before it has been successfully enabled (i.e. loaded returns true) Draw enters a degenerate state which is hard to recover from.

Even though this is more a concern for the Draw project rather than Mapbox GL JS I wonder if Map#isMoving and Map#isTilesLoaded covers the potential state queries a client or plugin would want to make. I imagine that adding draw would be possible before these states are fulfilled, but after the map's style is initialised.

I guess my question boils down to: What is the earliest state the map can reach when it is reasonable to add/remove controls/sources/layers and is it possible to query for this state?

[lucaswoj]

What is the earliest state the map can reach when it is reasonable to add/remove controls/sources/layers and is it possible to query for this state?

This state is when Map#loaded returns true, also marked by the Map#load event. If that doesn't work, I'd consider it a bug.

[averas]

@lucaswoj Currently Map#loaded returns false during any kind of transition, meaning that a 10s flyTo transition will block a plugin/client (such as Draw) from enabling itself if it is specifically waiting for Map#loaded to return true (which Draw is).

If I understand this ticket correctly Map#isMoving will take Map#loaded's place semantically while Map#loaded will instead return true once all tiles are loaded (and then possibly be renamed to Map#isTilesLoaded)

1. Isn't it viable to mutate sources/layers/controls before all tiles loaded but after the style is loaded?
2. Wouldn't a transition like a 10s flyTo mean that new tile requests would continuously get queued effectively meaning that Map#isTilesLoaded would also return false until the flyTo is completed?

[lucaswoj]

Currently Map#loaded returns false during any kind of transition, meaning that a 10s flyTo transition will block a plugin/client (such as Draw) from enabling itself if it is specifically waiting for Map#loaded to return true (which Draw is).

Good point. This is a real hole in our API.

If I understand this ticket correctly Map#isMoving will take Map#loaded's place semantically while Map#loaded will instead return true once all tiles are loaded (and then possibly be renamed to Map#isTilesLoaded)

Not exactly. Map#loaded returns true because as the map moves, new tiles have to be loaded; renaming the method to Map#isTilesLoaded would not change this behavior. Adding a Map#isStyleLoaded may be more useful.

1. Isn't it viable to mutate sources/layers/controls before all tiles loaded but after the style is loaded?

Yes. If this isn't already allowed, we should allow it.

2. Wouldn't a transition like a 10s flyTo mean that new tile requests would continuously get queued effectively meaning that Map#isTilesLoaded would also return false until the flyTo is completed?

Yes.

[mourner]

This was done in #3941