Malik
Alleyne-Jones

Tapping a pin opens a sheet at 45% of the screen; drag it and it goes to full height. Into that has to fit a photo grid, the name, whether it is open right now, a stat row, a recent review, a details block, and a primary action — while the sheet itself is a gesture target and the map stays visible behind it, since this is the one sheet in the app that deliberately does not dim its backdrop.

The obvious build fails in a specific way. Put everything in one scroll view and the action you came for scrolls off the top; nest a horizontal carousel inside a vertical scroll inside a draggable sheet and the gestures fight each other. You get a panel that technically contains the information and practically buries it.

Three decisions, each of which is really the same decision — take things out of the scroll view.

The action pill is not in the sheet. Like, save, share, and Go render through the sheet host's own footer slot, so the pill is a sibling of the scroll view rather than a child of it. It stays pinned across both detents instead of riding the content's transform when the sheet expands. The cost is that a footer lives outside the sheet screen's React tree, so it cannot reach screen context — the state it needs comes through an external store, and dismissing from a footer needs a different hook than dismissing from inside. Content reserves bottom padding so the last row never hides underneath it.

The sticky header slides, and never fades. It is driven by a scroll handler running as a worklet on the UI thread, and it animates translateY only. That is not a style preference: the header is a glass material view, and any alpha below 1 stops it sampling its backdrop, so a fade renders it fully transparent rather than faint. Sliding is the only way to hide it and keep the material alive. The offset it reveals at is measured from the title's own layout rather than hardcoded, so a name that wraps to two lines still hands off cleanly.

Heavy things get their own route. Reviews, the who-liked list, a single full review, reserve providers, directions apps, and the two share flows are each a separate sheet reached through one navigation hook. Nothing expands inline. Nested scrolling is limited to two horizontal strips, and the photo grid is a static layout with a full-screen viewer on tap rather than a pager, so there is no carousel competing with the sheet's own drag.

The sheet reads as one surface with a fixed action bar, and every row that has no data — including its divider — removes itself, so a thin listing collapses instead of showing empty labels. The tappable open/closed pill does two things at once: expands the weekly hours and scrolls to them, so "when do they close?" is one tap.

Worth saying plainly: I have no before-and-after numbers for this. Nothing was instrumented and no usability testing ran. The claim is that the structure is right — the primary action cannot scroll away, and no two gesture recognizers are arguing — not that a metric moved.

Follow someone and you should be able to see where they eat. The tempting build is a new screen: fetch their places, render a map, done. Then you own two maps — two sets of pin styles, two tap handlers, two de-duplication rules — and they drift apart the first time one of them gets a fix.

There is a second problem that only shows up in a shared feed. Someone's recent activity merges two separate review tables, and both use ordinary auto-increment integer keys on independent sequences. Row 7 in one and row 7 in the other are not the same thing, but as ids in a merged list they are indistinguishable.

Friend viewing is a mode on the map that already exists. A context holds either the user being viewed or nothing, and one derived boolean gates the overlay sources: the two non-liked layers return empty, and the liked layer re-points at the friend's places. Everything downstream — pin styling, tap handling, overlay de-duplication — is untouched, because as far as it is concerned nothing changed.

The server is the gate. One endpoint returns a user's liked places, and one abort_unless allows it only if you are that user or you already follow them — an accepted follow, not a pending request, which a test covers specifically. I want to describe that precisely rather than flatter it: it is one-directional, they need not follow you back, and it exposes their entire liked set. The client also hides the button when it should, but that is affordance, not enforcement. The server check is the only real one.

The camera turned out to be the fiddly part, so it became a pure function with its own tests. Fitting to a bounding box is fine until someone has liked exactly one place — then the box has zero area and the map SDK obligingly zooms to a blank view. The function returns padded bounds when there is an area and a centre-plus-fixed-zoom when there is not, with cases for no data, one pin, several pins at identical coordinates, and non-point geometry. The fly-to also fires at most once per entry, tracked by a ref, so a background refetch does not yank the map back from wherever the user panned it.

For the id collision, the feed now emits ids prefixed by their source table instead of the raw row id.

One map, two modes, and a fix that fails safe: if the friend's places fail to load, the map alerts and drops out of friend mode rather than sitting there empty. Leaving is a one-shot handoff — the viewed user is stashed and consumed once by the friends list, which reopens their profile.

On the ids, the honest scope is small and I would rather say so than inflate it. That value is consumed in exactly one place, as a React key, so the failure mode was duplicate sibling keys — not a tap opening the wrong record. There is no ticket, no log, and no report behind it. The accurate statement is that a collision was possible and is now impossible, found by reading the merge rather than by anything going wrong.