What each row in the timeline means

Every row is named after the store it is about and the kind of change. We build that name ourselves: nanostores has no actions, so there is nothing else to name a row after.

the row	what happened
`$counter/set`	an `atom` was written
`$user/setKey:name`	a `map` key was written
`$settings/setKey:theme.color`	a `deepMap` path was written
`$total/computed`	a `computed` recomputed with no write of yours open
`$counter/mount`, `$counter/unmount`	the store gained its first listener, or lost its last
`$late/register`	stores joined the tree
`$late/unregister`	stores left it
`$count/hotReload`	a file ran again and its stores were rebuilt
`config.theme.$x/set`	a nested store was written, headed by its whole path
`$all[0]/set`	a store in an array was written
`$root.value.$children[0]/register`	stores found inside one store’s value joined the tree

A row holds one write plus every recompute that write caused, which is why a computed store usually has no row of its own. Mount, unmount, register, unregister and hot reload are the lifecycle rows, and lifecycleEvents turns all five off together.

A throttled store draws at most one row a second, or one row per the rate its comment names. The writes it made inside that time are folded into the row that closes it, followers and all. Its value in the tree stays current; what you lose are the steps between those rows.

When stores join and leave

A register row never means startup. Everything registered before the first snapshot is already inside it, so a register row is always a late arrival:

a code-split chunk loaded, and a file of yours ran for the first time;
a factory or a loop made another store, $items [store] #2;
a binding adopted a store that some other code built;
trackStores ran after connectDevtools, which is the usual shape for stores listed by hand;
your app put a store inside a store you already hold.

An unregister row is the opposite: stores left the tree. untrack("cart") does it, and so does an edit that deletes the last store in a file, or a store your code no longer reaches while the app runs. A store you listed by hand stays until you untrack it. Rows already sent stay in the timeline either way: it is a record of what happened, not a view of what is reachable now.

A hot reload draws one row, not a pair

A file that both loses stores and gains stores while it runs again was hot reloaded. The two halves become one row, src/stores/cart.ts/hotReload, or $count/hotReload when only one store moved. Inside the row each store carries its own word: hotReload for a store that came back, register for one your edit added, unregister for one it dropped.

A lifecycle row that carries several stores is named after the module they belong to, src/stores/cart.ts/register, or after the path they share when your app built them inside another store’s value, $root.value.$children[0]/register.