Form component

[web-padawan]

Suggestion: implement the <vaadin-form> component.

Purpose

Cover a very common use case based on lacking support for native Form submission API for Custom Elements, see WICG/webcomponents#187 and also w3ctag/design-reviews#305

Use cases:

1. Get rid of the <iron-form> in the code

• vaadin-login is depending on it: https://github.com/vaadin/vaadin-login/blob/ed96ee8e014a3217bd8905fbdc3708737667580a/src/vaadin-login.html#L91
• <iron-form> pulls in a quite big <iron-ajax> dependency which we don't use at all

2. Get rid of the issues which <iron-form> has:

• proper support for both slotted input (Enable slotting the input field vaadin-text-field#273) and the one placed in Shadow DOM is tricky (issue link to be added)
• named slots are recognised as form elements and submitted, see prefix & suffix are received when using iron-form vaadin-text-field#216

3. Get rid of the <iron-form> in the demos

Form submission and validation examples are currently using <iron-form> without even explaining WTF is this and why do we need it:

• checkbox-group: https://github.com/vaadin/vaadin-checkbox/blob/b63e966d5e0925edc031df5634be1a01dc36304c/demo/checkbox-group-validation-demos.html#L31
• text-field: https://github.com/vaadin/vaadin-text-field/blob/09c5f86563daf2b49291f50e4b4a4eabbb7d5866/demo/text-field-form-demos.html#L13
• radio-button-group: https://github.com/vaadin/vaadin-radio-button/blob/3e83f27909f28ddff2a3f2605a6962c0c7fe6bb7/demo/radio-group-validation-demos.html#L12
• date-picker: https://github.com/vaadin/vaadin-date-picker/blob/6269fc6e3da3376284ca9bb785c2a143a42e434d/demo/date-picker-validation-demos.html#L12
• combo-box: https://github.com/vaadin/vaadin-combo-box/blob/9603fe7bb00dce9c4243d6bb8afad1a64b64e71d/demo/combo-box-validation-demos.html#L13
• select: https://github.com/vaadin/vaadin-select/blob/cdd38396a66705411d8037eedbb7e563c3ab8411/demo/select-validation-demos.html#L12

4. Get rid of the <iron-form> in the tests

Ultimate goal would be to drop the support for this external dependency, starting from the next major versions, e.g. in V15 (so that we reduce the vendor lock-in and promote our own stuff)

5. Provide the better UX and DX for <vaadin-form-layout> users:

• integration example needed: Add example of integration with iron-form (sign-in form) vaadin-form-layout#25
• full featured form expected: Users are expecting more than layout from vaadin-form-layout vaadin-form-layout#28

6. Provide the lightweight component for using with LitElement

Ideally, the <vaadin-form> should be vanilla Custom Element, it doesn't need Polymer or LitElement dependency). This way, we can attract LitElement users who will soon feel that they miss something like that.

7. Future ideas

• consider generating a form out of a JSON schema automatically

Implementation

The first version can be implemented by porting some parts of the <iron-form> code (and tests) and removing all the opinionated AJAX related logic.

And please, let's not make it commercial component.

[jouni]

Would this be more of a non-visual helper component, or could it also handle form field related functionality, like suggested in vaadin/vaadin-core#150?

Nevermind. My thoughts were stuck in form fields for some reason, and I didn’t realize this was about the whole form itself.

[heruan]

Probably this will also cover https://github.com/vaadin/vaadin-form-layout/issues/97 or if not, I'd suggest that 🙂

[web-padawan]

@heruan thanks for reminder. That is a slightly different thing, but it could be attempted to done within the same scope (at least, prototyping would make sense).

[jouni]

A “fieldset / field group” component was in the scope for V13, but it looks like it might be a bit tight and might not make it in time.

[abdonrd]

Any news? I love the idea! ❤️

[Haprog]

One implementation idea (which surfaced in a discussion with @tomivirkki) that might be worth prototyping was that it might be pretty simple to use a native <form> with automatically generated <input type="hidden"> elements for each form field which would be synchronized with the component values in the form (synchronized e.g. via value-changed event).

Maybe it would even be possible to implement this kind of feature in each component (a mixin maybe?) so a separate custom form element is not needed (at least for basic form submission). A component could check in connectedCallback if it is within a <form> (by traveling up the DOM crossing shadow boundaries if needed) and if so it could save a reference to the form and create an <input type="hidden"> in the form and update that whenever the component value changes. And we could use a similar strategy for enabling buttons to submit or reset a form (maybe by setting an extra property on the button).

Though we would also need to be able to prevent this from happening for components which are used as an implementation detail within another component, so that only the value of the top level component if propagated to the form.

[Legioth]

@Haprog What you describe sounds like a polyfill for the potentially upcoming Form Participation API.

[Haprog]

@Legioth I didn't actually think about that when writing the comment, but even better if this could be more of a standards based polyfill instead of custom behaviour/implementation.

Form Participation API (formdata and Form-associated custom elements) is already part of the HTML spec and implementation on they way at least in Chrome.

• Form Participation API w3ctag/design-reviews#305 (comment)
• Need callback for form submit data WICG/webcomponents#187 (comment)

[vlukashov]

There is an open proposal for a Vaadin Form library to help with creating forms with Web Components. Please join the discussion at https://github.com/vaadin/proposal-for-vaadin-form