# The runtime graph

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](https://squiggle.sh/docs/inspector/renders).

A finding on the [Performance](https://squiggle.sh/docs/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:

```shell
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](https://squiggle.sh/docs/agents). The graph works the same on a recording; see [Record and replay](https://squiggle.sh/docs/replay).