-
Notifications
You must be signed in to change notification settings - Fork 9
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
do not listen/handle programmatic route changes #490
Labels
Comments
robstoll
changed the title
do not handle programmatic route changes
do not listen/handle programmatic route changes
Dec 17, 2021
robstoll
added a commit
to tegonal/proximap
that referenced
this issue
Dec 17, 2021
…tains#489 switch between cities moreover: - water-fountains#490 do not handle programmatic route changes - fix some null vs. undefined issues - update mapboxgl to latest version not included yet in this commit: - loading fountains outside of a city
robstoll
added a commit
to tegonal/proximap
that referenced
this issue
Dec 17, 2021
…tains#489 switch between cities moreover: - water-fountains#490 do not handle programmatic route changes - fix some null vs. undefined issues - update mapboxgl to latest version not included yet in this commit: - loading fountains outside of a city
robstoll
added a commit
to tegonal/proximap
that referenced
this issue
Dec 17, 2021
…tains#489 switch between cities moreover: - water-fountains#490 do not handle programmatic route changes - fix some null vs. undefined issues - update mapboxgl to latest version not included yet in this commit: - loading fountains outside of a city
robstoll
added a commit
to tegonal/proximap
that referenced
this issue
Dec 17, 2021
…tains#489 switch between cities moreover: - water-fountains#490 do not handle programmatic route changes - fix some null vs. undefined issues - update mapboxgl to latest version not included yet in this commit: - loading fountains outside of a city
Note that we still need to listen for browser |
robstoll
added a commit
to tegonal/proximap
that referenced
this issue
Dec 17, 2021
I figured it would be enough to have a guard in MapService to not emit a new state in case it is the same as the current. Yet, I was proven to be wrong and it definitely better to not process a programmatic route change twice.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current implementation listens on routeParam and queryParam changes and acts accordingly, i.e. jump to the corresponding location on the map. This behaviour is desired for the first time when a user has entered a corresponding url in to the address bar.
Yet, once the user is on the page and e.g. flies to another city, where we change the route programmatically due to the city change, it is unnecessary to process the routeParam change in addition (and fly one more time to the corresponding location).
The text was updated successfully, but these errors were encountered: