What the engine can see

Basis does not compute a mathematical basis of your app. It samples when updates happen and guesses which pieces of state look independent.

This page is what that guess is based on, and where it fails.

What is recorded

• Which animation frame (requestAnimationFrame) an update landed in.
• What looked like the source: a user event, an effect, a store write, another piece of state.
• A coarse role: local state, context, or an integrated store.
• A short sliding window of recent ticks (tens of frames, not the whole session).

That is enough to say “these two keep firing together” or “this effect updates that state on the next frame.” It is not enough to say the architecture is wrong.

What is not recorded

• Values, types, or meaning. isLoading and isSuccess are just two named pulses.
• Your source. Dependency arrays are not parsed.
• Chains that span a long async gap. If a fetch comes back after the window, the two sides look unrelated.

How the guess is built (0.4 → 0.6)

These layers still all run. Newer ones did not replace the old ones.

• 0.4 — same-frame vs next-frame pairing. Catches “always together” and “effect caused a second paint.”
• 0.5 — same pairing, but local vs context is distinguished, so “this hook only copies Context” can be called out separately.
• 0.6 — those pairs are edges in a graph. Reports can point at an upstream source instead of every downstream update.

Browser scheduling will invent coincidences (one click updates three contexts). The graph treats those as siblings of the same event when it can, instead of as a chain.

How to read a report

Start at the source the report names (click, effect, store), not at every flagged variable.

• Several locals that always move together → maybe one status value.
• A local that only updates when Context updates → maybe just read Context.
• An effect that writes state every time its input changes → maybe derive during render.

If the pattern is intentional, ignore it or add // @basis-ignore on that file.