"Each block should have a 'key' attribute" warning in a paginated {#each} list

Short answer

Use the record's unique ID as the key, not the array index. In your case the warning is not just cosmetic: because your rows contain form inputs and a stateful child component, an unkeyed (or index-keyed) {#each} can reuse the wrong component instance when the slice changes, leaving stale input values attached to the wrong record.

1. Record ID vs. array index

Use the record's stable unique identifier:

{#each displayed as row (row.id)}
  <Row bind:value={row.note} />
{/each}

The index is a property of the current slice, not of the record. Your slice is rebuilt on every page change, so index 0 on page 2 is a completely different record than index 0 on page 1. With index keys Svelte sees "same key, new data" and patches the existing DOM/component in place instead of tearing it down. That is exactly the scenario the warning exists for.

One nuance: if every page change truly destroys and recreates the whole list (e.g., the component remounts because the load function re-runs), index keys may appear to work. But that guarantee breaks the moment allData changes without a remount — an insert or delete between page changes, a reactive refresh, or overlapping records between adjacent pages. The ID key is correct under all of these; the index key is only correct under an assumption you don't control.

2. Is the risk real, or just performance?

It's a correctness risk, not only performance. Svelte's unkeyed each-block updates by position: it mutates the existing row instances with new data rather than matching instances to records. Two concrete failure modes in your setup:

• Inputs: uncontrolled or partially controlled inputs keep their DOM value when the element is reused for a different record, so a typed value can "ghost" onto the wrong row.
• Child components: local state inside the child (expanded/collapsed flags, internal caches, pending edits) survives and is now associated with a different record.

With (row.id) as the key, Svelte matches instances to records: a record that disappears has its row destroyed, and a new record gets a fresh instance. That is the behavior you want for stateful rows.

3. Does keyset pagination change the strategy?

No. Keying is about record identity within the rendered list, not about how you fetched the list. Offset slicing and cursor-based pagination both produce "an array of records that may overlap with the previous render," so the record's unique ID remains the right key in both cases. Keyset pagination actually makes stable keys more valuable, since cursors are typically used with incremental/appended rendering where rows mount without a full rebuild — precisely where index keys fail.

Verification

1. Add (row.id) to the each block and confirm the dev-console warning disappears.
2. Type text into a row's input, navigate to the next page and back, and confirm the value is either correctly tied to its record or cleared — not attached to a different row. Repeat with an insert/delete in allData between page changes.

Assumption worth checking: this applies to Svelte 4 as you described. If you later migrate to Svelte 5, each blocks are keyed by default and the warning disappears, but providing an explicit key for stateful rows is still good practice.