Skip to content

feat(core): evaluate rule conditions through the Form Validator - #2645

Open
gigibiffi84 wants to merge 10 commits into
eclipsesource:masterfrom
gigibiffi84:feat/rules-via-form-validator
Open

gigibiffi84 wants to merge 10 commits into
eclipsesource:masterfrom
gigibiffi84:feat/rules-via-form-validator

Conversation

@gigibiffi84

Copy link
Copy Markdown

Part of #1498. Stacked on #2644 (Form Validator bridge) and #2643 (structural combinator selection); the diff shrinks to the last commit once those are merged.

What changed

Rule conditions (SchemaBasedCondition) were evaluated with ajv.validate(condition.schema, value), so rules were the last place where a custom Form Validator did not apply and Ajv code generation was unavoidable.

  • The ajv parameter of isVisible, isEnabled, isReadonly, evalVisibility, evalEnablement, evalReadonly and Runtime.isVisible/isEnabled is widened to RuleValidator: an Ajv instance (as before), a FormValidator, a FormValidatorFactory, or undefined.
  • New matchesConditionSchema(schema, data, validator) dispatches on the kind: Ajv keeps using ajv.validate; a Form Validator uses its optional matches, or the Structural Matcher from feat(core): select combinator branches structurally instead of compiling them with Ajv #2643 when it has none; a factory gets one Form Validator per condition schema, cached in a WeakMap; undefined uses the Structural Matcher alone.
  • New selector getRuleValidator(state): the configured Form Validator when a custom one is set (the bound one, or the option itself while validation is off), otherwise the Ajv instance. Core's own mappers (mapStateToControlProps, cells, layouts, enablement/readonly helpers) now pass it instead of getAjv(state).

For adopters

Nothing changes for Ajv users: passing an Ajv instance behaves exactly as before, and the built-in Ajv adapter's matches uses ajv.validate. Renderer packages that still call isVisible(..., getAjv(state), ...) keep compiling and working; switching them to getRuleValidator is part of the bindings PR. Adopters with a custom Form Validator that has no matches get structural rule evaluation (type, enum, const, required, additionalProperties, nested); numeric keywords in rule conditions need a matches implementation until the Structural Matcher is extended.

Tests

test/util/runtime.test.ts: all existing tests unchanged, plus a Form Validator with matches (calls recorded), fallback without matches, no validator at all, a factory called once per condition schema across evaluations, AND/OR composition, enablement and readonly, Ajv unchanged, matchesConditionSchema dispatch, getRuleValidator in all three states, and an isVisible integration where Ajv would throw if consulted. 532 core tests green; core, bindings and the React renderer sets build; typedoc succeeds.

🤖 Generated with Claude Code

gigibiffi84 and others added 10 commits June 5, 2024 09:21
The SET_AJV reducer compiled the schema with the new Ajv instance but
never wrote it to state, so every later setSchema or re-enabled
validation silently went back to the previous instance.

Part of eclipsesource#1498

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ing them with Ajv

Combinator tab selection compiled every oneOf/anyOf/allOf branch with
Ajv and then ignored all errors except the structural keywords
required, additionalProperties, type, enum and const. The new
isStructuralMatch evaluates exactly those keywords itself, recursively
through properties, patternProperties, items, $ref, nested combinators
and if/then/else.

Tab selection therefore no longer depends on an Ajv instance or on
code generation, so it also works under a Content Security Policy
without unsafe-eval. Equivalence with the previous filtered-Ajv
behaviour is covered by tests comparing both approaches keyword by
keyword.

Part of eclipsesource#1498

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Adds the validation seam from issue eclipsesource#1498 as a non-breaking addition:
the `validator` init/updateCore option takes a FormValidatorFactory
`(schema) => FormValidator` or a FormValidator already bound to the
schema. The types mirror the FormValidator / ValidationIssue of the 4.x
presentation-model branch, restricted to synchronous results.

- The core reducer creates the Form Validator through the factory
  whenever the schema changes and caches it in `state.formValidator`;
  `state.validator` keeps holding the compiled Ajv function when Ajv
  validates, so existing consumers are unaffected.
- Issues from custom validators are converted to the Ajv error shape
  the rest of core and the renderers read (`issuesToErrors`): missing
  `key` becomes `custom`, `required` issues addressed to the missing
  property are split into parent path plus `params.missingProperty`,
  non-error severities are dropped and a missing `parentSchema` is
  resolved from the form schema.
- `createAjvValidator(ajv?)` is the built-in adapter;
  `compiledAjvValidator(validateFn)` wraps Ajv standalone code for CSP
  setups without unsafe-eval.
- `getValidator(state)` exposes the bound Form Validator.
- Switching to NoValidation via setValidationMode now also drops the
  cached validator, as init and updateCore already did.

Precedence: `validator` wins, otherwise `ajv`, otherwise the default
Ajv instance. Existing users notice nothing.

Part of eclipsesource#1498

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Resolved with the bridge's reducer (which already stores the Ajv
instance on setAjv), both util exports, and both groups of reducer
tests.
Schema based rule conditions were always evaluated with
ajv.validate(condition.schema, value), the last place where a custom
Form Validator did not apply.

- Widen the `ajv` parameter of isVisible, isEnabled, isReadonly, the
  eval* functions and Runtime.isVisible/isEnabled to RuleValidator: an
  Ajv instance (unchanged behaviour), a FormValidator (its `matches`,
  or the Structural Matcher when it has none), a FormValidatorFactory
  (one Form Validator per condition schema, cached) or undefined (the
  Structural Matcher alone).
- Add matchesConditionSchema and the getRuleValidator selector; core's
  own mappers pass getRuleValidator(state) instead of getAjv(state).

Part of eclipsesource#1498

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@netlify

netlify Bot commented Oct 7, 2026 •

Copy link
Copy Markdown

✅ Deploy Preview for jsonforms-examples ready!

Name Link
🔨 Latest commit fb54f12
🔍 Latest deploy log https://app.netlify.com/projects/jsonforms-examples/deploys/6ac6840af286eb0008788868
😎 Deploy Preview https://deploy-preview-2645--jsonforms-examples.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant