Is your feature request related to a problem? Please describe.
Today JSON Forms holds a minimal central state (data, schema, uischema, errors, renderers, config, i18n, ajv etc.) and each renderer derives its own props on every render via mapStateToControlProps / ctxTo*Props / HOC chains. Consequences:
- Logic leaks into the "UI" layer. Required-label handling, visibility rules, enablement, error extraction, i18n key resolution, option computation, label derivation, path composition, etc., live in the mappers. Some renderers need more information and additionally access the central state to extract more information.
- Customization is coarse-grained. To customize cross-renderer functionality, e.g. change the "label" computation, you often need to override every renderer.
- Performance can be improved Every form change re-runs all mappers (e.g.
mapStateToControlProps) and thereby does path/schema/error work that could be memoized at a layer higher. The existing approach can be improved but might be more natural with a different approach.
We want to evaluate consolidating this logic into a centralized presentation model that lives in @jsonforms/core. Renderers become thin views over a single PM node.
Describe the solution you'd like
Core idea
The core builds and maintains a list of Presentation Nodes that mirrors the rendered form. Each node is framework-agnostic and carries everything a renderer needs to render itself: its resolved label, translated description, current data slice, error messages, visibility, enablement, and for containers all relevant information of their children.
Presentation Model construction
The presentation model is constructed by a builder pipeline that takes the current state and produces the presentation model. The presentation model is created on the expected visual representation, i.e. it will avoid endless recursive layouts by stopping once the edges of data are reached.
For every form change, the presentation model is updated, making sure to keep object identities for unchanged nodes. To actually gain performance compared to the current approach, we need a mechanism for partial updates instead of a full re-generation
Extensibility
- Renderer customizations work as before. Testers work against presentation nodes.
- Presentation model construction and updating should also be customizable, to allow straightforward cross-cutting customization
Backward compatibility
We could continue to offer the existing mappers and testers as a compatibility layer if it's worth it.
Key benefits
- The presentation model abstracts over the JSON Schema, enabling an easier integration with JSON Schema less approaches
- Clear separation between logic and rendering allows further integrations, e.g. exposing concise state of the form for AI agents, and more generic renderers
Describe alternatives you've considered
The first step is an evaluation whether this approach makes sense to be implemented at some point. We do not know yet whether we will actually go for this and whether the backward incompatibility and effort are worth it for the supposed gains.
Package
Core
Is your feature request related to a problem? Please describe.
Today JSON Forms holds a minimal central state (
data,schema,uischema,errors,renderers,config,i18n,ajvetc.) and each renderer derives its own props on every render viamapStateToControlProps/ctxTo*Props/ HOC chains. Consequences:mapStateToControlProps) and thereby does path/schema/error work that could be memoized at a layer higher. The existing approach can be improved but might be more natural with a different approach.We want to evaluate consolidating this logic into a centralized presentation model that lives in
@jsonforms/core. Renderers become thin views over a single PM node.Describe the solution you'd like
Core idea
The core builds and maintains a list of Presentation Nodes that mirrors the rendered form. Each node is framework-agnostic and carries everything a renderer needs to render itself: its resolved label, translated description, current data slice, error messages, visibility, enablement, and for containers all relevant information of their children.
Presentation Model construction
The presentation model is constructed by a builder pipeline that takes the current state and produces the presentation model. The presentation model is created on the expected visual representation, i.e. it will avoid endless recursive layouts by stopping once the edges of
dataare reached.For every form change, the presentation model is updated, making sure to keep object identities for unchanged nodes. To actually gain performance compared to the current approach, we need a mechanism for partial updates instead of a full re-generation
Extensibility
Backward compatibility
We could continue to offer the existing mappers and testers as a compatibility layer if it's worth it.
Key benefits
Describe alternatives you've considered
The first step is an evaluation whether this approach makes sense to be implemented at some point. We do not know yet whether we will actually go for this and whether the backward incompatibility and effort are worth it for the supposed gains.
Package
Core