Form validation and submit flow

[sashafirsov]

Form validation flow

Each form field on change can trigger either native ( by element implementation ) or DCE event-driven declarative "validation", i.e. DOM change according to input validity.

Alternatively, the "change" event is propagated from form inputs to the form element itself.

This is a natural choice for validation trigger on the form level and propagate the formData when slice is defined on the form element.

<form slice="my-form" >...

would use new FormData(formElement) as value for the form. The serializer should encode the <form-data> XML to be passed to http-request component.

<form slice="signin-form">
                    <label> Enter your email, phone, or user name
                        <input name="username" autocomplete="username"
                            placeholder="Email, phone, or username"
                        />
                    </label>
                    <fieldset>
                        <legend>Confirm by</legend>
                        <label><input type="radio" name="confirm-by" value="email"      /> email         </label>
                        <label><input type="radio" name="confirm-by" value="sms"        /> text to phone </label>
                        <label><input type="radio" name="confirm-by" value="password"   /> password      </label>
                        <if test="/datadom/slice/signin-form/form-data/confirm-by = 'password'">
                            <label>Enter password: <input type="password"/> </label>
                        </if>                      
                    </fieldset>
                    <button>Sign In</button>
                </form>

In the given example the password input would appear matching radio selection. During the selection change, the /datadom/slice/signin-form/form-data/confirm-by or simply //form-data/confirm-by if filled by the form change event handler.

custom-validity attribute

The DOM changes are not the usual outcome of validation. HTML5 has dedicated styling and special properties associated with form input elements.

The input form element has several read-only properties and methods available: validationMessage, validity, etc. To set the validity the only available method is setCustomValidity(message).

custom-validity attribute would set the message as an XPath expression by API ^^. It would require an extra post-render step with traversing of whole DOM or altering the DOM + rendered template merging algorithm.

    <form slice="signin-form">
         <variable name="warn"><if test="string-length(/datadom/slice/signin-form/form-data/username) &lt; 10 ">
                            user name or email should be longer of 10 symbols
             </if></variable>
         <input name="username" 
                     custom-validity="$warn" />                    
    </form>

Q. How to allow the default validity values along with custom ones?

Setting custom validity to blank would(?) eliminate the defaults. Setting to the particular value would override default ones also.

Wish: expose the validity form field property of ValidityState type.

Perhaps as part of the event source element on the slice.

should-submit form attribute for the form submit prevention

should-submit attribute would evaluate its value as XPath expression. The value would be

• preserved in event data to be used in UI as generic form event message
• evaulation to boolean ( i.e. not empty) would be used as return value for submit event.

Usually the form level validation is triggered by form submission flow.

The `change` event is available on the `FORM` element

```html ```

In order to prevent submission on invalid form data, the false should be returned by the submit event handler. ( MDN link? )

What if the error is already covered by input field and no need for separate form level message?

The boolean false value of XPath from should-submit can serve the indicator of error without the form level message. The UI should check this value from the form event slice and hide the message for false case, otherwise display the message.

[sashafirsov]

Form submission data

By default the action and method would define the data format and protocol for cross-page submission.

The custom-element can retrieve the page URL changes by <location-element live> . New page would need to reflect the URL for method="GET". There is no simple way of handling POST though. As an work around for POST across web pages without backend, is to utilize the service worker.

In SPA pattern, the form submit leads to http request by code and URL handling by routing mechanism on successful ajax completion. The transitioning state usually freeze the form to avoid the double submission and displayin the progress state as wording and animation. In the custom-element it means to pass the form-data to <http-request> via body attribute with XPath expression. The http-request would account the content-type and encode the body into JSON, XML, or string.

[sashafirsov]

expose native error data from browser API

• validationMessage with several read-only properties and methods
• validity form field property of ValidityState type
• checkValidity()
• reportValidity() Those data needed on form submission and input field events, i.e. can ba attached to event data.

What if async data change happen between form events, would the error messages disappear?

The event data would remain on field/form associated slise till relevant to the slice elements event occur.

[sashafirsov]

should-submit is very special name and associated business logic. The logic can be associated with custom-validity instead. The event on the form or form field, where the value of custom-validity XPath evaluation is not blank, would be interrupted by returning false by event handler.

[sashafirsov]

data in form lifecycle

Filled before custom-validity evaluated on change, submit and defined by slice-event events.

• form-data entry on form slice
• form-validity as field name:field.validationMessage object, multiple fields with same name TBD.
• form-fields as field name: [ { value, validationMessage, validity, name, id, slice }, ... ] - fields with same name - for future consideration.

The use of native validity capabilities is more accessible and device optimized than custom UI. See the form use example how to build UX by extending the validity instead of explicit error logic and UI control.

[sashafirsov]

23 defines slice relation