Engine support for `constraint`, `required` validation #154

As discussed in #140 Based on 4c38a22, with some refinements: - Each condition’s validity state is now represented by `valid: boolean` - Minor naming adjustments - Nailed down an initial pair of message constants for engine-fallback messages - Added a method to check whether a message is an engine-fallback, in a way that allows type narrowing and produces those message constants as types - Added a ton of JSDoc documentation clarifying the design, expected usage, some anticipated performance caveats, etc

Note: as described in the included TODO.md, this begins moving some parsing logic into a dedicated directory. This is a direction I’d wanted to take for some time. It felt particularly appropriate now because parsing these aspects of text no longer fits in the current body directory (itself entirely concerned with parsing, but only implicitly so), and it felt particuarly awkward to introduce another parsing-related top-level source directory (moving further *away* from this intent rather than inching towards it). I’d like to consider moving the rest of parsing logic into this directory within the same PR. It will almost certainly be just moving files and updating imports from here (and then TODO.md will never need to appear).

Note: this is intentionally a naive first pass! It does not defer computation as extensively as it could. I believe it is worth having that possibility documented, but measuring real world performance before optimizing further.

Note: this is also a naive first pass! Aggregated results are not stored in a client state object, but rather computed up from leaf nodes (where both engine/client state are read to ensure reactivity on both sides of that boundary).

…ngle node node-set This affects some `scenario` validation tests. It will also fix a few other tests which currently fail because of this difference in XPath/XForms boolean semantics (details in JSDoc).

- Form-specified constraintMsg, requiredMsg - Default/fallback messages for both conditions, as provided by the engine

In theory, we could do something like this to simplify children state logic as well, at least until we have a better general solution to storing/serializing/materializing complex nested state like direct references to node objects. I’d prefer to keep it isolated for now and think about priority of a more holistic solution.

As we discussed, this can be handled in a separate scope of work. The original commits are left intact for reference, we can rebase before merge if preferred.

Also eliminates most of the basis for the hacky custom client state solution, and so falls back to `createSharedNodeState`. This still isn’t ideal, as it’s redundantly storing a bunch of state that’s fundamentally derived. Worth considering whether the client interface should also accept an optional derived state factory (e.g. Vue’s `computed`, Solid’s `createMemo`).

…ed JSDoc

…node and form level)

Note: no change to aggregation necessary! Derived state is awesome.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Engine support for `constraint`, `required` validation #154

Engine support for `constraint`, `required` validation #154

Commits on Jul 12, 2024

Engine support for constraint, required validation #154

Engine support for constraint, required validation #154

Commits on Jul 12, 2024

Engine support for `constraint`, `required` validation #154

Engine support for `constraint`, `required` validation #154