-
-
Notifications
You must be signed in to change notification settings - Fork 782
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
How to distinguish user-initiated map move events from events fired as a result of programmatic APIs? #793
Comments
I think I needed this a while back but ended doing something else at the end. |
The problem is, the user has many ways to modify the maps. With the mouse, with touch, with keyboard (affecting pitch, bearing etc). It seems a little overwhelming to try and catch all of those different methods. |
Yea, I can't argue here, but I think implementing is as brittle as using it for the same reasons :-) |
IDK. |
I wonder if I can rely on the existence of
|
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
Yes that is a pretty stable solution and works for mouse (drag and drop), wheel, keyboard, touch. @HarelM , suggest close this issue. |
maplibre-gl-js version: (all)
Question
I need a way to respond differently to map move/pan/pitch/bearing events depending on those events being a result of user-interaction or programmatic API calls.
Reasoning:
We have a special mode where map view changes which are a result of user interactions are written to the DB.
Map movements which is a result of API calls do not.
One way to implement it is to add an
eventData
argument to all programmatic API calls as in:It can hold a flag which implies the event originates from an API call and not a result of user interaction.
This approach seems a little hackish thou. It requires updating every api call in the project: force an
eventData
arg for each, which is only used for this reason.It'd be so much more elegant to have this information built into the events by design.
It'll save the developer the effort of modifying the entire API calls set.
The
eventData
approach also involves an elevated risk for bugs; inexperienced developers could neglect providing a suitableeventData
arg, introducing very subtle bugs which are difficult to track down.Anyone else facing a similar issue? Perhaps I'm missing a better solution...
The text was updated successfully, but these errors were encountered: