Rover.fly_to/4 and Rover.fit_to/4 — a view that is a gesture, not state

[nseaSeb]

center and zoom are attributes, which is right when the view is a property of what you are rendering. It is the wrong tool for "the user clicked a row, take me there": passing center costs you the automatic framing (fit falls back to false, the centre stops being derived), so you trade the default behaviour for one gesture and hold the view in assigns from then on.

{:noreply, Rover.fly_to(socket, "clients", {client.lat, client.lon}, zoom: 15)}
{:noreply, Rover.fit_to(socket, "fleet", vehicles_on_shift, max_zoom: 15)}

Commands, not state. Nothing assigned, no attribute changed — and because the config never moves, the next unrelated re-render cannot pull the view back. The suite asserts exactly that: fly to Paris, recolour a parcel, check the centre held.

Rover.bbox/1 is public alongside them: markers, shapes, plain coordinates, a mixed list, or a box passed through. It drops unusable coordinates rather than raising, matching <.map>.

Two of the three new guards were worthless until sabotaged

This is the part worth reading.

• The fit assertion compared the new zoom >= the old one — satisfied by doing nothing at all. Stubbing fitTo to return immediately still passed. The playground now fits a single marker with max_zoom: 17, so the assertion is an exact zoom that inaction cannot reach, and it covers the max_zoom plumbing as a side effect.
• The id filter had nothing to be wrong about with one map on the page. Removing it passed. Hence a second map in the playground — which also demonstrates two maps in one LiveView, a capability nobody had verified.

All three now fail when broken:

Sabotage	Result
id filter removed	1 failed
fitTo does nothing	1 failed
max_zoom ignored	1 failed

148 Elixir tests, 48 Node tests, 7 browser scenarios.

🤖 Generated with Claude Code