Don't delay moveend event on invalidateSize

[jfirebaugh]

This causes unnecessary nondeterminism in the sequence of events emitted. Instead, the caller should be responsible for throttling, as e.g. Map#_onResize does.

@mourner Does this make sense? The setTimeout is causing a problem for OSM.org -- sometimes the moveend triggers stuff 200ms later that should have happened synchronously with invalidateSize.

[jfirebaugh]

osmlab/openstreetmap-website@9ed8664 is the relevant OSM commit.

[mourner]

Hmm, that one needs some thought... Some internal Leaflet stuff is happening on moveend as well, such as vector layer clipping and simplification, so that could introduce a performance hit. Also, it would make the event inconsistent with the standard panning behavior — e.g. I'd expect it to behave similarly to panning, fire move during resize movement and moveend when you stop.

[mourner]

@jfirebaugh can you clarify the problem with the 200ms delay on OSM.org? Perhaps we could explore alternative ways to fix this.

[jfirebaugh]

Yes, the problem is that the OSM.org code keeps track of the map state via history APIs -- there's a moveend event binding that updates the state via replaceState. Meanwhile, when the sidebar is shown or hidden in response to navigation events, we need to invalidateSize. But because invalidateSize fires moveend asynchronously, we have no proper control over which history entry is updated with the new state. It ends up being the wrong one if you click the back or forward button too quickly. Simply put, this use cases depends on invalidateSize firing moveend synchronously.

[jfirebaugh]

fire move during resize movement and moveend when you stop

FWIW, a 200ms timeout doesn't really accomplish that either -- you'll still get intermittent moveend when pausing for more than 200ms while resizing.

[mourner]

If the hash depends on moveend being sync, why not update it on move instead of moveend? Performance concerns?

[jfirebaugh]

Yeah, move happens a bit too often to update the hash, which flashes a loading indicator and may add a "Full History" entry.

[mourner]

But then you would fire lots of moveend events while resizing, having the same performance problem.

FWIW, a 200ms timeout doesn't really accomplish that either -- you'll still get intermittent moveend when pausing for more than 200ms while resizing.

It's at least an approximation, which is much better.

I'm sure there's a better solution to this problem, lets think more about other options...

[mourner]

@jfirebaugh what do you think about this: fire moveend sync by default, but debounce if some special option is specified (which is then passed in resize handler)? Should solve the issue.

[mourner]

Lets solve this before 0.7 release so that the redesigned OSM.org can use the stable version.

[jfirebaugh]

👍, added a debounceMoveend option.

[mourner]

Thanks, merged!