effect

effect(fn) runs fn once, then re-runs it when any cell it READS changes, and not otherwise. It is the only place side effects belong: the body is not re-executed on unrelated renders, so you never fetch twice or log in a loop by accident.

									
										component Search() {
  const &[query] = track('')
  const &[results] = track<string[]>([])

  effect(() => {
    const q = peek(query)
    if (q === '') {
      results = []
      return
    }
    fetch('/api/search?q=' + encodeURIComponent(q))
      .then((r) => r.json())
      .then((data) => { results = data.items })
  })

  <input value={query} onInput={(e) => query = e.target.value} />
  <ul>
    for (const item of results) {
      <li>{item}</li>
    }
  </ul>
}
									
								

Effects are client-only

An effect body does NOT run during server rendering. On the server a component renders once, synchronously, to a string — there is no live graph to update and nothing to re-run, so effect bodies are skipped and the component renders with whatever the cells hold at that moment.

For work that genuinely belongs to the browser — a timer, a pointer listener, localStorage, the canvas API — being client-only is exactly right. Use {#client} if you need browser APIs during setup itself; reach for on_destroy when you only need teardown.

Ordering is guaranteed

An effect is a block in the same tree as your render blocks, and a flush walks them in a fixed order: pre-effects, then render blocks, then effects. So by the time your effect runs, the DOM it is about to measure has already been updated. You never have to defer work to a microtask to be sure the markup exists.

									
										component Measure() {
  const &[label] = track('a fairly long label')
  const &[width] = track(0)
  let box: HTMLElement | null = null

  effect(() => {
    const text = peek(label)
    if (box === null) box = document.querySelector('[data-measure]')
    width = box.getBoundingClientRect().width
  })

  <div data-measure>{label}</div>
  <span>Measured {width}px</span>
}
									
								

Cleanup is the return value

Return a function from the effect body and the runtime calls it before the next run and again when the block is destroyed. You do not compare dependencies to decide whether to tear down — the block re-runs wholesale, so its teardown always runs first. This is the part that makes an effect a complete lifecycle primitive rather than a bare 'when this changes' hook.

									
										component Clock() {
  const &[now] = track(new Date())

  effect(() => {
    const handle = setInterval(() => { now = new Date() }, 1000)

    // Runs before each re-run, and when the component is destroyed.
    return () => clearInterval(handle)
  })

  <time>{now.toISOString()}</time>
}
									
								

For teardown that belongs to the component rather than to any particular effect run, on_destroy is the clearer spelling.

									
										component Clock() {
  const &[now] = track(new Date())

  on_destroy(() => clearInterval(handle))

  let handle: ReturnType<typeof setInterval> | null = null

  effect(() => {
    handle = setInterval(() => { now = new Date() }, 1000)
  })

  <time>{now.toISOString()}</time>
}
									
								

How this compares

Vesk borrows the good parts of a signal system — you never write a dependency array, and you never leave one behind when you add a new state read. Where it goes further is in what surrounds that.

What not to use it for

• Fetching data the first paint needs — use useFetch or createResource. They run on the server; effects do not.
• Deriving a value — use derived. An effect that computes and writes a cell renders twice, and a derived that writes throws.
• Event handling — use onClick. An effect has no idea WHEN the user meant to act.
• Reading state once — use peek/untrack, so the code does not subscribe by accident.