Skip to main content

See What I See

Mid-incident, a dispatcher has the perfect setup: four cameras pinned, map parked right over the fire. Describing that over the radio — "pin Bald Mountain North, then pan the map to…" — is hopeless. So the app has a better verb: share the view. One link, and the recipient opens the app seeing exactly what the sender sees.

The design problem is what makes this interesting: the recipient has preferences of their own, and they'd be rightly annoyed if clicking a colleague's link permanently rearranged their app. A shared view must borrow the recipient's screen — and then give it back.

How the borrow works

The shared link carries the sender's setup — pinned camera ids, excluded camera ids, and the map position:

interface SharedView {
pinnedCameraIds: string[];
excludedCameraIds: string[];
latitude: string;
longitude: string;
zoom: number;
}

Opening the link stashes that object in localStorage under the key sharedView. Then comes the elegant part: nothing else changes. No special "shared mode," no second code path. The same UI-settings query that loads everyone's preferences simply checks for the stash on its way through:

const applySharedViewOverrides = (resp: UiSettingsResponse) => {
const sharedViewString = localStorage.getItem('sharedView');
if (sharedViewString) {
const sharedView = JSON.parse(sharedViewString);

resp.hiddenCameras = sharedView.excludedCameraIds;
resp.pinnedCameras = sharedView.pinnedCameraIds;
resp.mapExtent = {
lat: sharedView.latitude,
lon: sharedView.longitude,
zoom: sharedView.zoom,
};

localStorage.removeItem('sharedView'); // ← the "give it back"
}
return resp;
};

The response is edited in flight: the server sent the recipient's own preferences, the override swaps in the sender's, and the whole app downstream can't tell the difference — pins, hidden cameras, and map position just are what the query returned.

And the removeItem on the way out is the entire return policy. The override applies exactly once: the recipient looks at the sender's setup, makes whatever adjustments they like, and on the next refresh their own preferences resume as if nothing happened. Their server-side settings were never touched.

Wrapping up

A shared view is one localStorage stash, one in-flight edit of the settings response, and one removeItem — borrow, show, return. No mode, no flag, no server state. It's the cheapest feature in this chapter precisely because user preferences already flow through a single query worth intercepting.

That closes the features chapters. Ready to go deeper? Start the advanced track: When Pixels Become Degrees.