Freegle / Iznik / 24463

72%

push

circleci

fix(browse): apply the saved sort/post-type on first load, not just after a manual change

A member whose saved sort is "Closest" (settings.browseSort='Nearby') still saw the
feed in the default "New to you" (Unseen) order on load - the distances looked
unsorted - and it only switched to Closest once they re-picked the sort by hand.

Root cause: the browse page's `selectedSort` (and `selectedType`) refs default to
'Unseen'/'All' and were only ever updated by PostFilters' `update:selectedSort` emit,
which fires on a manual change. PostFilters' own dropdown reads settings.browseSort for
display, so it *showed* "Closest" while the parent state driving the sort stayed
'Unseen' - and PostFilters is lazily mounted inside the collapsed "Map & Filters"
panel, so its getter didn't even run until the panel was opened. selectedMaxDistance
already worked around this by initialising from settings straight away (see the watcher
just above); sort and type were simply never given the same treatment.

Fix: initialise selectedSort and selectedType from settings.browseSort / browseType
immediately (and reactively, for async `me` load), mirroring selectedMaxDistance. Now
the saved sort is honoured on the very first render.

This is the missing half of the "Closest" fix: the earlier change made the Nearby sort
order by the server's per-post distance, but it never ran because selectedSort wasn't
'Nearby' on load. Verified end-to-end in the browser against a real member's live feed
(reach feed, 64 posts) - the list now renders strictly nearest-first
(<1mi, 3, 3, 5, 5, 6, 6, ...). Full vitest suite green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AsgvoSgfeUwBMBbxKJHSNy

12186 of 16110 branches covered (75.64%)

Branch coverage included in aggregate %.

0 of 22 new or added lines in 1 file covered. (0.0%)

129987 of 182415 relevant lines covered (71.26%)

37.87 hits per line