Week 070 — MapBox SearchBox
The map gets a search interface. The location UX gets a rethink.
Week of March 23, 2026
Progress
The lost location flow had a gap: geolocation captures where the user is now, not necessarily where they lost the item. A user filling out the form from home, reporting a wallet lost downtown, would get the wrong location automatically captured.
The new approach: auto-capture current location as the starting point, but give the user a MapBox SearchBox to refine or override it. They can search for any address or landmark, or clear the location entirely if they don't want to share or don't know.
The radius circle was added to the map — a visual ring showing the search area around the reported location. Getting the radius update to work correctly after a search result was selected required some work; the issue was the SearchBox zooming in automatically after selection, which made the radius ring appear to not be painting. It was painting, just outside the view. This was accepted as a MapBox behavior rather than a bug.
A map indexing refactor: the code had been using a global lostMap variable. When the item page needed multiple map instances (lost location + found location), a single global wasn't enough. Replaced with a dictionary of map instances indexed by container name. This also fixed a side effect where loadMap was returning a value assigned to window.onload, which caused issues.
The Hard Part
Two days were spent on a MapBox token issue — the SearchBox token wasn't being passed correctly. It turned out to be a typo. Typos in API tokens are invisible until you look very carefully.
Next Week
Clear location button. Wire up the location data to the save flow.
