Skip to content

Fix: "Use my location" lost the user's location on the search page#20

Open
GreerBK wants to merge 1 commit into
mainfrom
claude/fix-location-search
Open

Fix: "Use my location" lost the user's location on the search page#20
GreerBK wants to merge 1 commit into
mainfrom
claude/fix-location-search

Conversation

@GreerBK

@GreerBK GreerBK commented Jun 2, 2026

Copy link
Copy Markdown
Owner

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.

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant