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.