Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#3,997 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, typescript
Área
frontend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
36.2k
Forks
1.1k
Merge medio
10 h 34 min
PR fusionados (30 d)
364

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de solidjs/solid

Todos los issues de solidjs/solid

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.