Form component to simplify the form validation

[Nesqwik]

The problem

To add a form in a lenra app, we curenly have no other way than storing all the input current value into a data every time we receive a change event.
Then when the button is clicked, retreive this data and create our "real" new data.

This is highly annoying and should be simplified.

One possible solution

To fix this issue, we could add a Form component. This form could be linked to multiple inputs and a validation button.
When the validation button is pressed, a form event is sent to a listener which include the value of all linked input.
Simple and efficient.

{
  "type": "form",
  "children": [{
     "type": "checkbox",
     "value": false,
     "ref": "accept_email"
  }, {
     "type": "textfield",
     "value": "[email protected]",
     "ref": "email"
  }, {
    "type": "button",
    "submit": true,
    "value": "OK"
  }]
}

Could send the event data :

{
   "accept_email": false,
   "email": "[email protected]",
}

Client side form validation

Using this form, we could add some constraints to each inputs. When the form is validated (or dynamically when the user change the field) we could validate the input and print an error if needed.

{
   "type": "textfield",
   "validation" : {
       "required": true,
       "maxLength": 10,
       "minLength": 2,
       "regex": "..."
   }
}

Server side form validation

Since this form validation is never enough to ensure security, the validations should also be checked server side.
Since all the necessary informations are already present in the json, we could also validate the event sent to the server using these data. For example, if event.form.isValid == true then the dev can trust the values in the form and add them to the stored data.

[taorepoara]

What is the comportment for a textfield in a form that have a listener defined ? Is the textfield content also part of the form data or not ?

[Nesqwik]

If a textfield does have a listener AND is linked to a form, both event (the default textfield and the form one) should be fired IMO.

The name of the properties does not matter, there is a lot of possibilities to add a textfield to a form.

• By default for all children of the form component (could be limiting but it's easier)
• Set a name property to a form, add a listener to this form and link the inputs to the form using a ref.

We could also simply not use any form by using any button :

• Set a name property to the button, add the listener to this button and link the inputs tu the button using a ref

The downside of using a button component (instead of a form) is the scope. The button name have to be unique and there is no scope for the inputs They can be anywhere in the page. It's more permissive but it allows messy code with name collisions.

[taorepoara]

I think the form scope is the simpler solution even if it's less permissive. Also we can submit the form by pushing the Enter key in a textfield.

[Nesqwik]

After discussion, this is what we choose :

• The inputs are linked to the first form above in the tree but can be anywhere under in the tree.
• The form have a onSubmit listener that is triggered by the "Enter" key on a textfield or a click on the submit button
• One or many button can have "submit": "true" property to be the submit button
• We must Implement the "next" button on mobile
• Autocomplete fields must works

With this form :

{
  "type": "form",
  "onSubmit": {
    "action": "registerNewsletter",
    "props": {"from": "homePage"}
  }
  "children": [{
     "type": "checkbox",
     "value": false,
     "name": "acceptEmail"
  }, {
     "type": "textfield",
     "value": "[email protected]",
     "name": "email"
  }, {
    "type": "button",
    "submit": true,
    "text": "OK"
  }]
}

The onSubmit event looks like this :

{ "value": {"acceptEmail": false, "email": "[email protected]"}}

[jonas-martinez]

The problem with using a children property for the form component is that there is no proper way to display the children. In fact, does the client want to display them in a Row or a Column ? We could add some properties for that but that would be duplicating some of the logic of the LenraFlex component.

That is why in my opinion we should follow the Flutter's implementation on that one. They use a child property instead so that the user can take care of the styling of the children.

[Nesqwik]

Indeed, the child property seems to be the best option !

[taorepoara]

Done