Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#3,997 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript, typescript
Lĩnh vực
frontend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
36.2k
Fork
1.1k
Merge trung bình
10 giờ 34 phút
Pull request đã merge (30 ngày)
364

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của solidjs/solid

Tất cả issue của solidjs/solid

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.