Rendering Lists with For

Rendering a list in React almost always means array.map(...). In Solid, .map still runs — but <For> is the component you should reach for, because it changes how list updates are handled, not just how the loop is written.

What .map alone gets you (and costs you)

function List(props) {
  return (
    <ul>
      {props.items.map((item) => <li>{item.name}</li>)}
    </ul>
  );
}

This renders correctly on initial creation. The problem shows up on updates: .map has no concept of tracking individual items — if props.items changes at all, Solid's reactivity has no fine-grained way to know which specific <li>s actually changed, so this pattern tends to force recreating the whole list on any change to the array.

For tracks items, not just the array

import { For } from "solid-js";

function List(props) {
  return (
    <ul>
      <For each={props.items}>
        {(item) => <li>{item.name}</li>}
      </For>
    </ul>
  );
}

<For> takes the array via each and a render function as its child. Internally, it keys each rendered item to a specific array entry (by reference, for objects) and diffs the array between updates — so adding one item to a 1,000-item list creates exactly one new <li>, reorders references it can reuse, and leaves the rest of the DOM completely untouched. This is the direct list-rendering equivalent of the fine-grained updates you've seen with signals: update only what actually changed.

The index is a signal, not a fixed number

The render function's second argument is the item's index, but — importantly — it's a signal accessor, not a plain number:

<For each={props.items}>
  {(item, index) => (
    <li>{index() + 1}. {item.name}</li>
  )}
</For>

You call it as index(). This matters because an item's position can change (items get inserted, removed, or reordered) without the item itself being recreated — the index needs to be reactive so the displayed position stays correct even when the underlying DOM node for that item is reused rather than rebuilt.

Keying by identity, not by array index

Because <For> keys by item reference, list items should generally be objects (or at least distinguishable values) rather than raw duplicate primitives:

// Fragile — identical strings can't be distinguished as separate entries
<For each={["A", "A", "B"]}>{(item) => <li>{item}</li>}</For>

// Solid — each object is a distinct reference, even with identical fields
<For each={[{ id: 1, label: "A" }, { id: 2, label: "A" }, { id: 3, label: "B" }]}>
  {(item) => <li>{item.label}</li>}
</For>

Index vs For: a quick decision rule

Solid also has an <Index> component, which keys by position instead of by value — useful for a fixed-size list of primitives (like a grid of independent toggle states) where you want each DOM slot to stay put even as the value in it changes. For nearly all everyday lists — data fetched from an API, arrays of objects — <For> is the right default, and it's the one you'll use far more often.