angular: propagate the enabled state to detail renderers instead of modifying their UI schema

Offen
#2,630 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
68/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
angular, typescript
Bereich
frontend

Rechercherichtung

Start with packages/angular-material/src/library/util/detail-uischema.ts and the jsonforms-outlet, LayoutChildrenRenderPropsPipe, LayoutRenderer, array layout, object control, list-with-detail, and table renderer entry points named in the issue. Trace how enabled currently reaches React and Vue equivalents, then compare Angular's cloneDeep/setReadonly paths. Done means enabled state reaches nested detail renderers while the supplied UI schema remains unchanged.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

angular material
Is your feature request related to a problem? Please describe.

Follow-up to #2628.

The Angular Material array layout, object control and list with detail disable their detail by calling setReadonly on its UI schema, which writes options.readonly: true into every control. That UI schema is the result of findUISchema, i.e. the user's options.detail or a UI schema from the uischemas registry. #2628 stopped modifying the user's object by deep cloning it first (createDetailUiSchemaResolver in packages/angular-material/src/library/util/detail-uischema.ts), but the renderers still render a modified copy instead of the given UI schema.

The other renderer sets never modify a given schema or UI schema. React and Vue hand the parent's state down as the enabled own prop of JsonFormsDispatch / DispatchRenderer, and isInherentlyEnabled (packages/core/src/mappers/util.ts) falls back to ownProps.enabled.

Downsides of the current Angular approach:

  • The detail UI schema is deep cloned whenever one of its inputs changes, and the renderers need memoization so that this does not happen on every state emission.
  • Toggling the enabled state produces a different UI schema. jsonforms-outlet compares UI schemas with isEqual, so it destroys and re-creates the whole detail, losing any view state inside it, e.g. the selected tab of a nested categorization.
  • Nested and custom renderers receive a UI schema containing readonly options the user never wrote.
Describe the solution you'd like

Propagate the enabled state through the Angular bindings like React and Vue do, and render the detail UI schema as-is:

  • jsonforms-outlet: accept enabled (already part of OwnPropsOfRenderer) in renderProps and hand it to the created renderer, e.g. as disabled on JsonFormsAbstractControl, which getOwnProps already maps to ownProps.enabled.
  • Layout renderers: forward the enabled state to their children, e.g. via LayoutChildrenRenderPropsPipe, so it reaches controls nested in layouts inside a detail. LayoutRenderer currently only takes label and visible from mapStateToLayoutProps.
  • Array layout, object control and list with detail: pass enabled: this.isEnabled() along with the detail's render props and drop the cloneDeep + setReadonly.
  • Table renderer: same for its generated cell UI schemas, which also get setReadonly today.
Describe alternatives you've considered
  • Keep cloning the detail UI schema (current state since #2628). It works and no longer modifies the user's UI schema, but keeps the costs and the view re-creation described above, and stays inconsistent with the other renderer sets.
  • Resolve the readonly state centrally in @jsonforms/core (e.g. a parent-enabled lookup by path) instead of passing props down. This would avoid touching every layout, but has no precedent in the other bindings.
Package

Angular Bindings, Angular Material Renderers

Additional context
  • Once nothing in Angular Material uses them anymore, setReadonly and unsetReadonly in @jsonforms/core (packages/core/src/util/uischema.ts) have no remaining users and could be deprecated.
  • This is a behaviour change for Angular users: controls inside a detail would be disabled via the inherited enabled state instead of a readonly option. For example, an enable rule on a control inside a disabled array keeps taking precedence in both approaches, but custom renderers reading uischema.options.readonly would no longer see it.
Vorherrschende Sprache
TypeScript
Sterne
2.8k
Forks
423
Ø Merge
5 T. 16 Std.
Gemergte PRs (30 T.)
9

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus eclipsesource/jsonforms

Alle Issues in eclipsesource/jsonforms

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.