Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Keep element state when the runtime moves a node (`moveBefore()` and not detaching what is re-inserted)

オープン
  • 何か問題がありますか？
#3,997 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
javascript, typescript
領域
frontend

調査の方向性

Start by reading the keyed reconcile and insert paths, then trace the swap path that uses replaceChild and how removals are ordered against inserts when nodes migrate between parents. Benchmark moveBefore() against insertBefore on those hot paths and measure the cost of deferring removals; performance is the decision gate. Done means deciding the scope and fallback behavior, then validating the behavior and performance against the stated acceptance scenario.

索引モデルが issue の本文から書いたものです。

説明

enhancement

Summary

When a DOM node changes position, @solidjs/web moves it with
insertBefore / replaceChild, and in some cases removes it first and
inserts it afterwards. The browser treats each of these as a removal and an
insertion, so state that lives on the element's connection to the document is
reset: focus, CSS animations and transitions, iframes (they reload), popover
and fullscreen state, and so on.

Element.moveBefore() moves a connected node without that reset. Adopting it
would let Solid 2.0's "one element, several positions" behaviour keep that
state too. This issue is to track it. It needs performance vetting before
any decision.

Where it shows up

  • Keyed lists. A focused row that is reordered loses focus.
  • An element referenced from more than one position (the
    migrating-element example; a card created once and referenced from
    whichever list holds it). The node keeps its identity, listeners, value and
    selection, but loses focus, and an <iframe> or a running CSS animation
    would restart.
  • In an app this reads as: an editor that stays open with its draft intact
    but has to be clicked again after someone else moves its card, and a
    keyboard "move this item" shortcut that works once and then has nothing
    focused.

What was measured

Chromium 152, dev build, origin/next at 2322d6407. One board-level
mapArray creates each card element; three lists' <For>s reference the
elements of the cards they hold; a store write moves a card. DOM calls on the
card element were logged by patching the prototypes.

Case Calls the runtime made
Card moves to a list that updates before the one it leaves one insertBefore on the connected node
Card moves to a list that updates after the one it leaves remove(), then insertBefore on the detached node
Reorder toward the front of a list one insertBefore on the connected node
Reorder toward the end of a list replaceChild, then insertBefore on the detached node

With a focused <input> inside the moved element:

Same element, value, selection Focus
As shipped kept in every case lost in every case
Connected-node insertBefore routed through moveBefore() (patched in the page) kept kept in the single-insert cases only

A raw-DOM baseline agrees: moveBefore() on a focused input keeps focus, and
appendChild loses it.

So there are two separate parts:

  1. Use moveBefore() when the node being inserted is connected (same
    document, and the other preconditions the method has).
  2. Do not detach a node that the same flush re-inserts. Today about half
    of the moves above detach first, and no move API can help a node that is
    already disconnected when it is inserted.

Part 2 is the larger change. It touches the reconcile's swap path
(replaceChild then re-insert) and the ordering of one position's removal
against another position's insert when a node migrates between parents.

Open questions

  • Performance. moveBefore() on the hot paths (keyed reconcile, the
    insert path) against insertBefore, in the usual benchmarks, plus the cost
    of the feature check and of any deferral of removals for part 2. This is
    the gate.
  • Support. Not in every browser yet (Chromium and Firefox have it,
    Safari does not, as far as we know at the time of writing; versions to be
    confirmed against MDN). Feature-detect and fall back; a browser without it
    behaves as today.
  • Preconditions. moveBefore() throws where insertBefore does not (a
    disconnected node, a different document, some shadow-root cases). Each
    call site needs the check or a fallback.
  • Custom elements. With moveBefore() an element gets
    connectedMoveCallback if it defines one; otherwise the disconnected and
    connected callbacks still run. Worth stating in the docs.
  • Scope. Reorders within one parent only, or migration between parents as
    well (which is where part 2 matters most).
  • Semantics to document. What survives a move today (identity,
    listeners, value, selection, canvas bitmap) and what would be added (focus,
    animations, iframes, popover and fullscreen state).

Not measured

Firefox and Safari. <iframe>, <video>, CSS animations and popovers (the
migrating-element README's open question about media). Focus was set from
script, and moveBefore() was simulated by patching insertBefore in the
page, not by changing the runtime.

Acceptance test this would unblock

In a board example that is in progress: open a card's title editor in one tab and type half a
word; move that card to another list from a second tab. Today the editor
stays open with the draft and selection intact, and focus is gone. With this
work the next keystroke lands in the editor. The example also carries a
one-line refocus after keyboard moves that could then be deleted.

主要言語
TypeScript
スター
36.2k
フォーク
1.1k
平均マージ
10時間 34分
マージ済み PR（30日）
364

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

solidjs/solid のほかの issue

solidjs/solid の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。