really appreciated - it's somewhat debounced already, but it seems to be not quite right... I'd be curious to hear about how you went about debouncing (what time delays on which specific actions, zoom, moving the map)

Option one: Use the built-in `idle` event on the top-level map object. This basically does all the debouncing for you, though I don't remember off the top of my head whether this event happens before or after the `tilesloaded` event. The distinction would only be important if you want to wait for the map to visually update before displaying the results.

Option two: I think for your use case just listening on the single `bounds_changed` event will do what you want. That should trigger for all types of map movement or zooming. For the callback, use a closure which clears and sets a timeout event with the desired debounce time; no need to overcomplicate it. Then it's just tuning the delay until it hits that sweet spot between firing too often and obvious visual delays.

there's some pretty interesting statistics to do with price changes - chances of finding something better are biggest when you book somewhat further in advance (say, 60 days) & travel to big cities - then we do find better prices in about 50% of the cases what makes me happiest is crazy stuff, like a $600 better rate for a $1300 hotels somewhere on the strip in LA (happened a few weeks ago)

dev here; yea, we're using EAN for sourcing the hotels that people initially book - but we have many more other OTAs integrated for tracking prices the way you could look at it is that we try and capture peoples traveling intent with an API which is relatively easy and fast-performing, then we try in our own time to find something better