state/editing? outlives the editor's textarea

Abierto
#1,481 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Refactorización
Claridad
Necesita aclaración
Estado de actividad
Activo
Área
backend

Línea de trabajo

Read the :editor/editing? state and state/get-input callers, then trace the editor component lifecycle and the shortcut and CodeMirror paths described in the issue. Compare the two proposed meanings of editing? and identify which callers need each; done means maintainers have chosen a consistent state contract that prevents stale textarea access.

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

Descripción

state/editing? outlives the editor's textarea

state/editing? (:editor/editing?) can stay true for a moment after the block editor's textarea has left the DOM: the block was just deleted, the editor closed, a re-render replaced it. In that window state/get-input returns nil while everything that asks editing? still treats the user as editing. Code that trusts editing? and then reads the textarea throws.

A local key fuzzer that records uncaught page errors found this through several entry points:

  • block-editing shortcuts (Alt+E, Alt+A, Alt+U, Alt+K, the word movement and word delete shortcuts): fixed for the whole shortcut group in #13865 by requiring a live input in the group's gate;
  • Up/Down at the edge of a code block (CodeMirror's own key handler, outside the shortcut gate): get-prev-block-non-collapsed got a nil block (also in #13865);
  • earlier, cursor helpers and paste handlers reached through other paths.

#13865 removes the crashes but leaves the state as it is: any new code that checks editing? and reads the textarea can hit the same thing.

The design question

Should editing? mean "a block editor textarea is mounted"? Options:

  • clear :editor/editing? when the editor component that set it unmounts without another taking over (care is needed for re-renders that unmount and remount the same editor);
  • or define editing? as (some? (get-input)) for callers that act on the textarea, and keep the current flag for callers that only need "a block is being edited".

This touches editing state everywhere, so it is a question for the maintainers rather than a patch.

Lenguaje dominante
Sin datos de lenguaje
Estrellas
29
Forks
2
Métricas de merge de PR
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 logseq/db-test

Todos los issues de logseq/db-test

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.