validateSubmission
validateSubmission(
form,data,options):ValidationErrors
A client-side port of the server’s own submission validation, for immediate feedback before a step advances or a form submits.
The server remains authoritative. These rules exist so a respondent sees a mistake without a round trip, not to be trusted — a client bypass still gets a real 400. They are kept deliberately identical to the server’s, down to the message strings, and one shared set of test cases is run through both implementations so a divergence fails a test rather than surfacing as “the SDK said this was valid and the API disagreed”.
Like the server’s, this is a basic shape check by design — no email regex on an Email-variant input, for instance. It enforces the constraints a field definition actually declares, not stricter invented formats. Native browser validation still applies on top.
collectDataFields is answers-aware: a field inside a Variant
branch that isn’t currently satisfied by data is simply absent from fields below, so it is
never required and a value submitted for it is flagged the same as any other unrecognized key
(“Unknown field.”). That is a deliberate simplification from the server’s own two-message
distinction (“Unknown field.” vs. “This field was not shown and cannot be submitted.”) — the
server remains authoritative for that nuance, and a respondent can’t reach this case through this
component’s own UI anyway, since EbitexForm prunes a hidden field’s answer from data the moment
its controlling condition stops being satisfied (see that component’s own setValue).