Askr
Fundamentals

Lists with For

Use lists with for with the current published Askr packages.

  • @askrjs/askr0.0.59

How to use lists with for

Render stable keyed rows and keep row identity separate from array position.

  1. Import the published @askrjs/askr entrypoint.
  2. Keep lists with for configuration next to the component, route, or server composition root that owns it.
  3. Handle pending, unavailable, cancellation, and failure states, then verify the production path.
import { For } from '@askrjs/askr';

<For each={projects()} by={(project) => project.id}>
  {(project) => <ProjectRow project={project} />}
</For>

Keyed lists

`<For each={items} by={item => item.id}>{(item, index) => ...}</For>` is how Askr renders collections — `each` accepts an array or a function returning one, and the `by` callback supplies a stable string or number key per item. The render callback receives the item plus an `index` accessor function (not a raw number), since an item's position can change as the list reorders.

Identity and reordering

Keys are what let `For` tell the difference between an item moving and an item being replaced. Internally the runtime tracks commit strategies like `INSERT_ONE`, `REMOVE_ONE`, `SWAP`, and `FULL_KEYED` to patch the DOM with the smallest possible change instead of tearing down and rebuilding rows, but that only works if `by` returns a key that's stable across renders for the same logical item. If you don't need per-item keys, `byIndex: true` opts into index-based identity instead of the `by` callback.

Empty collections

`For` accepts a `fallback` prop that renders when `each` produces zero items, so you don't need a separate `Show` wrapped around every list to handle the empty case. The fallback is regular JSX — a message, an empty state illustration, whatever — and it's swapped back out automatically the moment the source has items again.

List performance

Because `For` diffs by key rather than re-rendering every child on every source change, updating one item in a thousand-item list only touches that item's DOM node. The render callback's `index` parameter is a reactive accessor rather than a plain number specifically so that reorders don't force a full re-render of every row just to update its position — only rows that actually read the index value respond when it changes.