Fix: "Use my location" lost the user's location on the search page#20
Open
GreerBK wants to merge 1 commit into
Open
Fix: "Use my location" lost the user's location on the search page#20GreerBK wants to merge 1 commit into
GreerBK wants to merge 1 commit into
Conversation
Clicking "Use my location" on the home page navigates to
#/search?lat=..&lng=..&distance=50. On the search page, the URL→state
sync effect re-creates fresh array references for the filter state,
which trips the auto-apply effects. Those call applyFilters(), which
rebuilt the query string purely from the component's own state — and
because the location arrived via the URL (this component's geolocation
state is null in that case), applyFilters had no lat/lng to write back
and silently dropped them. The user landed on the search page with no
location applied, so results were not sorted/filtered by distance.
This also affected any shared or bookmarked /search?lat=..&lng=.. URL
and any future code path that puts a location in the URL.
Fix (src/App.jsx, applyFilters):
- Location precedence is now: this component's geolocation, else a
lat/lng present in the URL, else a typed zip. The URL fallback keeps
the "near me" location alive when the user changes any other filter.
- Added a no-op guard: if rebuilding the query produces the current
URL, skip navigating. This neutralizes the spurious mount-time
auto-apply (and prevents redundant history entries / reload loops).
Fix (src/index.css):
- .btn-loc ("Use my location") was ~35px tall; added min-height:44px
so it meets the WCAG 2.5.5 touch-target minimum like other buttons.
Verified in a local preview: navigating to
#/search?type=Boxing&lat=44.9778&lng=-93.265&distance=25 now preserves
all params (previously lat/lng/distance were wiped within ~80ms).
Production build passes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Clicking "Use my location" on the home page navigates to #/search?lat=..&lng=..&distance=50. On the search page, the URL→state sync effect re-creates fresh array references for the filter state, which trips the auto-apply effects. Those call applyFilters(), which rebuilt the query string purely from the component's own state — and because the location arrived via the URL (this component's geolocation state is null in that case), applyFilters had no lat/lng to write back and silently dropped them. The user landed on the search page with no location applied, so results were not sorted/filtered by distance.
This also affected any shared or bookmarked /search?lat=..&lng=.. URL and any future code path that puts a location in the URL.
Fix (src/App.jsx, applyFilters):
Fix (src/index.css):
Verified in a local preview: navigating to
#/search?type=Boxing&lat=44.9778&lng=-93.265&distance=25 now preserves all params (previously lat/lng/distance were wiped within ~80ms). Production build passes.