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

feat(workflow-form): Form View widget refinements (render canvas-only widgets fully, HuggingFace mode, compile-on-blur)

Abierto
  • ¿Algo no está bien?
#8,439 2 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@yangzhang75 ya está trabajando en esto.

Desde el 6/9/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

Refinements surfaced in review of the Form View render PRs (#8437 render inputs, #8436 field-type rules). All are out of scope for the MVP, which ships clean fallbacks; filing so they are not lost. Part of the Form View feature (#8011).

1. Render the code editor in the form (not a fallback)

An exposed code-editor property currently falls back to a plain editable control (CANVAS_ONLY_FORMLY_TYPES), and is not offered for exposure at all (NON_FORM_FIELD_TYPES). The code editor is not an inline field: it is a button that opens Monaco via createComponent into a ViewContainerRef the workspace registers, keyed off the canvas's highlighted operator. The form has neither, so rendering it here means giving the form its own editor host and supplying the operator id from the binding (plus a change to the shared codearea component). Raised by @mengw15 on #8436.

2. Render Projection's drag-reorder list in the form (with the drag)

An exposed drag-reorder property currently falls back to a plain repeated list (CANVAS_ONLY_FORMLY_TYPES). The widget is a FieldArrayType whose rows come from an item template the panel builds with extra dynamic-schema wiring for Projection's attributes; the reorder callback itself is optional (the form's valueChanges persists a reorder). Rendering it with the drag needs that item-template wiring reproduced and verified against the real schema. Overlaps the nested/array work in #8438. Raised by @mengw15 on #8436.

3. Full HuggingFace form-view mode

An exposed HuggingFace model picker (modelId) now gets the operator's other properties (including task) as read-only context, so it loads the right models and labels the field, and only the bound property is written back. Not yet handled: the widget's own task selector is still interactive and a task change is not persisted, so a reader could in principle pick a model/task pair the operator's real task does not match. A form-view mode would use the provided task and hide/lock the task selector. Touches the shared hugging-face.component. Raised by Copilot on #8437.

4. Compilation update dropped while the reader is typing

The inputs rebuild on the compilation-state stream, skipped while the reader is typing so it does not throw away a half-entered value. The stream is a ReplaySubject(1), so a state update that arrives during typing is dropped and not replayed once focus leaves the field; if it carried new upstream column names, an attribute control stays a plain text box until an unrelated compilation. Record a pending rebuild and flush it on blur. Raised by Copilot on #8437.

5. Read-only lock must block keyboard too, not just pointer

The read-only input card uses pointer-events: none, which only blocks pointing-device hit testing. A keyboard user can still tab to a custom widget's own controls (a file picker button, the HuggingFace file input) and activate them with Enter/Space -- e.g. the HF audio input ignores formly's disabled control and POSTs the selected file. Use the inert attribute on the card (or disable each descendant control semantically) so read-only blocks keyboard interaction too. Raised by Copilot on #8437/#8438/#8440.

6. ui-udf-parameters overrides in the form

ui-udf-parameters is exposable, but its renderer hides formly's labels and shows hard-coded column headers (Value / Name / Type), so a binding's displayName/hidden sub-field overrides do not change what the reader sees. Either fall back to an override-aware Form View renderer for this type, or have the component consume the nested labels/visibility. Same class as the HuggingFace form-mode item above. Raised by Copilot on #8438.

  • Form View result-frame rebuild churn (from #8441 review): the Form View bumps a viz result key on every result-update emission, destroying/recreating the visualization iframe, which defeats VisualizationFrameContentComponent's own throttled (auditTime 2s) in-place self-update. Fix: bump the key only when a result is genuinely new (first appearance / re-run), handling clearResults (a separate stream) so a re-run still gets a fresh frame without reintroducing the stale/undefined-picture bug the key was added to fix. Must be verified on a flag-on instance (the iframe cannot render in jsdom).
Lenguaje dominante
Scala
Estrellas
316
Forks
192
Merge medio
3 d 5 h
PR fusionados (30 d)
124

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 apache/texera

Todos los issues de apache/texera

Issues similares

Más issues de Scala

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.