Web Canvas

Why I did it this way

1. Reanimated for the viewport, Skia for the ink

   Pan and zoom run on the UI thread, so a gesture never waits on JavaScript and the canvas holds 60fps with a dozen live web pages on it. Skia draws the parts that are drawings: the connection lines, the grid, and the thumbnails in the sessions list.

2. Analytics that can’t see a URL

   Event names are a fixed list and each event’s fields are typed, so no call site can invent a field. The rule the code enforces is that no full URL, search or note text ever reaches the analytics provider.

3. Everything stays on the device

   Sessions, history and settings live on the device. Sharing a session produces a link that points at a canvas already on that device, so nothing is ever uploaded. The cost is no sync between devices, which is the most common request we get.

4. Screenshots from seeded canvases

   Store screenshots are captured by Maestro against named canvases built through a dev-only link, so a shot is the same every run instead of hand-arranged. It also turned up a measurement that changed the plan: note text is about 4pt once a full canvas is zoomed to fit, so one screenshot can’t show both the whole canvas and readable notes.

5. Color that flows down a connection tree

   A color set on an item is inherited by everything connected below it unless a child overrides it. That’s what lets a line of research read as one group when you’re zoomed out too far to read any text.