Tech Blog.

Thoughts, stories, ideas.

Validation des formulaires avec Ember.js

10. January 2017

Les formulaires sur les sites Web sont si omniprésents et évidents qu’on y pense rarement. Néanmoins, il est probable que chaque internaute se souvienne rapidement d’un formulaire qui ne fonctionne pas de manière optimale. En particulier lors de la validation des formulaires, il semble y avoir un nombre infini de variantes, bien qu’en 2017 il y ait encore beaucoup de formulaires défectueux à l’état sauvage.

Qu’est-ce qui fait une bonne forme ?

L’enregistrement, la validation des formulaires et la validation du certificat d’authenticité sont des éléments essentiels qui doivent être pris en compte dans un formulaire d’enregistrement :

 

 

 

 

 

 

 

 

 

  • Est-ce que je sais à l’avance quelles données doivent être saisies dans les différents champs du formulaire ?
  • Quand serai-je informé d’éventuelles erreurs dans mes entrées ?
  • Puis-je corriger ces erreurs facilement ?

Une bonne mesure de la qualité d’un formulaire est le temps moyen qu’il faut aux utilisateurs pour le remplir. La recherche des “meilleures pratiques” pour la validation des formulaires permet d’obtenir divers, bon articles, qui comparent différentes variantes.

Au lieu de sauter directement aux recommandations concrètes pour de bonnes formes, il vaut la peine de considérer d’abord quelques règles de base pour la conception des interfaces utilisateur. Certaines entrées de Aral Balkan’s “User Interface Design Principles” peuvent être appliquées directement aux formulaires et à leur validation :

  • Prévenez, ne réprimandez pas: Une bonne interface utilisateur prévient les erreurs au lieu de réprimander l’utilisateur avec des messages d’erreur.
  • Donner une feed-back suffisant: L’utilisateur n’a jamais à se demander si une action particulière vient de fonctionner ou non. L’interface utilisateur est en dialogue permanent avec l’utilisateur par le biais d’un retour visuel.
  • Innocent jusqu’à preuve du contraire: Un message d’erreur pour un champ de formulaire ne doit être affiché qu’une fois que l’utilisateur a terminé sa saisie dans ce champ.

A partir de l’essentiel et des résultats des différentes études, nous pouvons définir quelques exigences pour une bonne forme :

  • Le formulaire est bien étiqueté. En plus d’un nom significatif pour la zone de formulaire, ceci inclut également – si nécessaire – un texte descriptif. La base devrait être ici la probabilité d’une erreur de l’utilisateur. Une description “Max. 50 caractères” dans le champ nom d’utilisateur n’est pas utile, un indice pour une politique de mots de passe exotique (“Au moins 8 caractères, pas de caractères spéciaux sauf _ . :”) est plus utile.
  • Une fois la saisie terminée, l’utilisateur reçoit immédiatement un retour d’information: Les messages d’erreur s’affichent lorsque vous quittez le champ du formulaire (onBlur).

Formulaires dans Ember.js

C’est maintenant le moment d’appliquer ce que vous avez appris dans le cadre du frontend de votre choix. Dans le Adfinis SyGroup c’est actuellement Ember.js.

Comme nous le savons du monde JavaScript, il existe de nombreuses solutions différentes pour chaque problème. Ember Observer liste 32 addons dans la catégorie formulaire, Google trouve 222’000 résultats pour la’validation des formulaires membres’. Toutefois, certains résultats méritent d’être soulignés :

  • ember-validations: Nr. 1 dans Google-Suchergebnis, 873 Github-Stars. Toutefois, la première phrase du fichier README se lit comme suit :

> Cet addon n’est plus activement développé. Chez DockYard, nous sommes passés à l’utilisation des validations ember-changeset conjointement avec ember-changeset.

  • ember-changeset : Fournit un Changeset qui mappe les changements d’un modèle Ember y compris d’éventuelles erreurs de validation. Forme avec ember-changeset-validations une bonne base pour les validations de toutes sortes.
  • ember-form-for : Premier résultat de recherche dans Ember Observer. Fournit une API très simple et pratique pour la définition des champs de formulaire :
{##form-for newUser as |f|}}}

{f.text-field "firstName"}}}

{f.text-field "lastName"}}}

 

{{f.select-field "gender" "unknown male female"}}}

{f.date-field "birthDate"}}}

{/form-for}}}

 

Malheureusement, ember-form-for ne fournit pas de support prêt à l’emploi pour masquer les erreurs de validation jusqu’à ce que l’utilisateur ait interagi avec le champ (voir Issue #122).

A partir de cette situation, le nouvel addon ember-validated-form a été créé dans notre dernier projet Ember. Il fournit une API similaire à ember-form-for et utilise ember-changeset et ember-changeset-validations pour la validation. Avec l’addon, nous poursuivons les objectifs suivants :

  • Concentration explicite sur la validation des formulaires. La validation des formulaires côté client ne doit pas seulement être un aspect secondaire, mais l’objectif principal.
  • Un UX prêt à l’emploi. Les messages d’erreur ne s’affichent que surBlur ou après avoir cliqué sur le bouton submit.
  • Gardez les choses simples. Au lieu de mettre en œuvre une multitude de composants de coffrage différents, il faudrait pouvoir intégrer des éléments de coffrage spéciaux eux-mêmes.

Le modèle d’un formulaire type avec formulaire validé par un membre ressemble à ceci :

{{#validated-form

model = (changeset model UserValidations)

on-submit = (action "submit")

submit-label = 'Save' as |f|}}

 

{{f.input label="First name" name="firstName"}}

{{f.input label="Last name" name="lastName"}}

 

{{f.input type="textarea" label="About me" name="aboutMe"}}

 

{{f.input

type = "select"

label = "Country"

name = "country"

options = countries

value = model.country

}}

 

{{f.input type="radioGroup" label="Gender" name="gender" options=genders}}

 

{{/validated-form}}

Pour les règles de validation, ember-changeset-validations est utilisé :

// validations/user.js

import {

validatePresence,

validateLength

} from 'ember-changeset-validations/validators';

 

export default {

firstName: [

validatePresence(true),

validateLength({min: 3, max: 40})

],

lastName: [

validatePresence(true),

validateLength({min: 3, max: 40})

],

aboutMe: [ validateLength({allowBlank: true, max: 200}) ],

country: [ validatePresence(true) ],

gender: [ validatePresence(true) ]

};

Avec Bootstrap, le résultat ressemblera à ceci :

 

 

 

 

 

 

 

 

…et peut aussi être essayé par vous-même.

Conclusion

La validation des formulaires n’est pas un sujet facile et, comme souvent, il n’existe pas de solution brevetée.

Néanmoins, nous espérons que le ” formulaire validé par les membres ” aidera à réduire le nombre de formulaires frustrants sur le Web à l’avenir. Nous sommes impatients de recevoir vos commentaires sur Github !