The runtime graph
For AI agents: this page is Markdown at https://squiggle.sh/docs/inspector/graph.md. Every docs page is listed at https://squiggle.sh/llms.txt, and all of them are one file at https://squiggle.sh/llms-full.txt.
The Graph tab draws your app as Squiggle sees it: every component coloured by how often it renders, joined to the stores and queries it reads. Use it to see what re-renders, and what made it.
Read the graph
The default view is a tree of your components. Each one is coloured by render count, from green through amber to red, and pulses when it renders. Coloured arcs join each component to the stores and queries it reads.
So a component that re-renders on every keystroke shows as a red node with an arc back to the store that drives it: the effect and the cause in one picture.
The other view lays the same graph out by connection instead of by tree, so things that depend on each other sit close together. It is better for exploring, worse for finding one component.
What’s in it
| Node | What it is |
|---|---|
| Component | Every mounted component, with its testID, role, text, source line, render count and props. |
| Screen | The screens the app has shown. |
| Store · Query | Zustand stores and how often they changed; TanStack Query entries with status and fetch count. |
| Gesture · Animation | Touches the app recognised, and running animations. |
| Network · Crash · Action | Requests, errors with their stacks, and the actions your app named with defineAction. |
Squiggle also records cause: each tap is linked to the renders, store changes and requests it set off. So “this tap caused these fourteen renders” is something Squiggle saw, not a guess. None of this needs setup; the SDK records it for the libraries your app already uses.
Move around
Drag or scroll to pan. Pinch, or ⌘ + scroll, to zoom. Click a node to zoom to it. Fit to view frames the whole graph. Selecting a component here selects it everywhere: on the device, in the tree and in Details.
Count what re-renders
The Renders tab lists the components that re-render most, what set each burst off, and which providers re-render their consumers for nothing, and it warns you about render loops. See Find what re-renders.
A finding on the Performance screen links here with the component it blames already selected.
Query it instead
Everything the graph shows is also stored, so you can ask with SQL. For example, every component that rendered more than 20 times in the latest session:
squiggle perf sql " select name, count(*) as renders from renders where session_id = (select session_id from sessions order by started_wall desc limit 1) group by node_id, name having renders > 20 order by renders desc"Your agent reads the same data through the query and probe_read tools; see Connect your agent. The graph works the same on a recording; see Record and replay.