fix(url-sync): don't overwrite URL position params on initial load

[rayanhabib07]

Root cause

Race condition in setupUrlStateSync(). applyInitialUrlState() calls
map.setCenter() which starts an async flyTo animation. setupUrlStateSync()
was then immediately calling debouncedUrlSync() — 250ms later the debounce
fired while flyTo was still running, reading the default center
(lat=20, lon=0, zoom=1) and writing it back over the URL params.

Fix

Skip the immediate debouncedUrlSync() call when URL position params
(lat/lon/zoom) are present. onStateChanged fires on moveend after flyTo
completes, at which point getCenter() returns the correct position and
handles the first URL write.

Test plan

• Load /?lat=41.0089&lon=0.0000&zoom=4 — URL params should persist after 1–2s
• Load with no params — URL sync still works normally on map interactions
• Load with only ?view=mena — immediate sync still fires (no position params)

[vercel]

@rayanhabib07 is attempting to deploy a commit to the Elie Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

This PR fixes a race condition in setupUrlStateSync() where the initial debouncedUrlSync() call (250 ms debounce) would fire while a flyTo animation was still in progress, reading the default map center (lat=20, lon=0, zoom=1) and overwriting the URL params the user intended to share.

Key changes:

• setupUrlStateSync() now checks whether lat, lon, or zoom are present in ctx.initialUrlState before firing the immediate debouncedUrlSync() call.
• When position params are present, the immediate sync is skipped and the first correct URL write is delegated to the existing onStateChanged handler, which fires on moveend after the flyTo animation completes.
• When no position params are present (e.g. ?view=mena), behavior is unchanged — debouncedUrlSync() fires immediately as before.
• The logic correctly uses optional chaining (?.lat) to handle the null typed initialUrlState, and the undefined check aligns with how parseMapUrlState represents absent parameters.

Minor edge case (P2): When lat/lon are in the URL but effectiveZoom ≤ 2, the pre-existing guard in applyInitialUrlState() skips setCenter() — no animation fires, so onStateChanged never triggers the first URL write. The URL is preserved but stays out of sync with the actual map state until the next user interaction. This is a narrow edge case and unlikely to affect real users.

Confidence Score: 5/5

Safe to merge — the fix is narrowly scoped, correctly handles the race condition, and only skips an erroneous initial sync that was clobbering URL params.

The single changed file makes a minimal, well-targeted fix. The logic is sound: urlHasPosition correctly identifies the case where applyInitialUrlState() starts an async flyTo, and the onStateChanged/moveend path reliably handles the deferred first write. The only remaining finding is a P2 edge case involving the pre-existing effectiveZoom > 2 guard interacting with the new skip logic — not a regression introduced by this PR and very low real-world impact.

No files require special attention beyond the one P2 edge case noted on src/app/event-handlers.ts.

Important Files Changed

Filename	Overview
src/app/event-handlers.ts	Adds urlHasPosition guard in setupUrlStateSync() to skip the immediate debouncedUrlSync() call when lat/lon/zoom are present in the initial URL — correctly prevents the 250 ms debounce from reading the default map position and overwriting URL params while a flyTo animation is in progress.

Sequence Diagram

sequenceDiagram
    participant App
    participant PanelLayout
    participant EventHandlers
    participant Map
    participant URL

    App->>PanelLayout: applyInitialUrlState()
    PanelLayout->>Map: setCenter(lat, lon, zoom)
    Map-->>Map: flyTo animation starts (async)

    App->>EventHandlers: setupUrlStateSync()
    EventHandlers->>EventHandlers: urlHasPosition = (lat/lon/zoom in initialUrlState)?

    alt urlHasPosition = false (no position params in URL)
        EventHandlers->>EventHandlers: debouncedUrlSync() fires after 250ms
        EventHandlers->>Map: getCenter() returns default (lat=20, lon=0, zoom=1)
        EventHandlers->>URL: replaceState(default position) BUG
    else urlHasPosition = true (position params present) NEW BEHAVIOUR
        EventHandlers->>EventHandlers: skip debouncedUrlSync()
        Note over Map,URL: flyTo animation runs...
        Map-->>EventHandlers: onStateChanged fires on moveend
        EventHandlers->>EventHandlers: debouncedUrlSync() fires after 250ms
        EventHandlers->>Map: getCenter() returns correct position
        EventHandlers->>URL: replaceState(correct position)
    end

Loading

_{Reviews (1): Last reviewed commit: "fix(url-sync): don't overwrite URL posit..." | Re-trigger Greptile}

[greptile-apps]

Silent gap when zoom ≤ 2 with lat/lon present

In applyInitialUrlState() there is an existing guard that skips setCenter() when effectiveZoom <= 2:

if (lat !== undefined && lon !== undefined) {
  const effectiveZoom = zoom ?? this.ctx.map.getState().zoom;
  if (effectiveZoom > 2) this.ctx.map.setCenter(lat, lon, zoom); // ← skipped when zoom≤2
}

When a URL like ?lat=41&lon=0&zoom=1 is loaded:

1. urlHasPosition is true (lat/lon/zoom are all defined), so debouncedUrlSync() is correctly skipped by the new guard.
2. However, because effectiveZoom <= 2, setCenter() is never called — no flyTo animation is started, and moveend never fires.
3. onStateChanged therefore never fires from the animation, meaning the first URL write is silently dropped. The URL retains the original params indefinitely until the user manually interacts with the map.

Before this PR the old debouncedUrlSync() call would at least update the URL to the actual map state (even if with the wrong position). After this PR the URL is preserved but permanently out of sync with the map's actual position until the next user interaction.

The practical impact is low — a URL with zoom=1 or zoom=2 alongside explicit lat/lon is an unusual combination, and the user interacting with the map immediately restores consistency. But if precise URL-shareability on initial load is important, you may want to call debouncedUrlSync() explicitly after applyInitialUrlState() when setCenter() was skipped for this reason.