Formulaires surpuissants avec Remix, Zod et Conform

00:18 Dans cette vidéo, je vais te montrer comment je développe des formulaires très puissants avec feed back utilisateurs et validation côté client et côté serveur. Et nous allons le mettre en place avec le framework remix et la librairie conforme. Je me rends sur le site de remix dans get started et je vais instancier un nouveau projet en cliquant sur NPX create remixe et en le copiant. J'ouvre un terminal, je vais dans un dossier et j'entre la commande. On va appeler le projet remix-forms.

00:44 On veut utiliser un repository et on veut installer toutes les dépendances avec NPM. Maintenant que c'est fait, je vais ouvrir le projet VSCode. Je vais ouvrir le terminal et faire un NPM run dev pour lancer le serveur de développement. Je clique maintenant sur le lien localast trois mille pour ouvrir mon application. On va ouvrir l'explorateur de fichiers et nous rendre dans le dossier app root index.

01:07 Tfi et dans ce fichier, je vais quasiment tout supprimer je vais laisser le div et le h1 on va d'abord ajouter un formulaire en html on va donc rajouter un élément forme puis un input de type texte et un bouton avec le message soumettre. On peut voir sur ma page que j'ai mon in-pot et j'ai le message. Et si je clique, il ne se rien mais du rl a changé et elle a rajouté un point d'interrogation parce qu'on n'a pas encore spécifié de nom notre formule je vais donc rajouter un nom qui aura comme propriété name vais actualiser la page et maintenant je vais au sommet le formulaire avec une valeur je vais mettre vergile j'ai cliqué sur soumettre et cette fois on voit que ça m'a rajouté un paramètre d'URL qui a comme clé name et comme valeur vergile. C'est un formulaire get classique en réa. Mais dans cette vidéo, on ne va faire que du post.

01:51 Je vais donc tout de suite rajouter méthode égal post à mon formulaire. Ensuite, si on retourne sur la documentation de Remix et qu'on tape dans la barre de recherche forme et qu'on clique sur le premier lien, on peut voir que remix met à disposition un composant spécial de formulaires et c'est celui qu'on va utiliser aujourd'hui. Il est à peu près pareil que cet élément forme avec un f minuscule sauf que le f est en majuscule et il possède quelques trucs en plus. Donc je remplace mon élément, j'importe le composant depuis remix run, sachez que maintenant je vais de nouveau soumettre le formulaire et on peut voir qu'on a une erreur, quatre cent cinq méthodes natala hall et cette erreur est liée au fait que nous venons de faire un post sur une route avec remix sauf que le traitement de notre poste se fait côté serveur c'est à dire que toutes les valeurs de notre input peuvent être traitées côté serveur pour ajouter une logique serveur notre application remix on va devoir exporter une variable qu'on va appeler action une méthode qui renverra pour le moment nul et on peut tout de suite mettre cette méthode en a cinq.

02:46 Je vais actualiser la page et je vais rentrer mon prénom je vais soumettre le formulaire et on peut voir qu'on n'a plus d'erreur. Si je clique sur inspecter et que j'ouvre les outils de développement et que je me rends dans network, on va réeffectuer une soumission de formulaire et sinon les on voit que je fais bien un post sur ma route dans le payload. On peut voir que j'ai un form data, donc des données de formulaires avec comme clé name et comme valeur verger et j'ai envoyé cette donnée sur la route maintenant ce qu'on a envie de faire c'est de rajouter un petit peu de validation côté client et côté ça donc côté client je vais rajouter un mean l'ens et je vais mettre qu'on puisse pas avoir un prénom inférieur trois caractères je vais donc maintenant m'appeler Joe et vais soumettre le formulaire et on peut voir que j'ai un message natif html qui me demande de mettre minimum trois caractères grâce à ces attributs une laine et ça c'est un propre natif html va nous permettre de rajouter ses propres natifs en utilisant la librairie de validation z ce que j'ai envie maintenant c'est de rajouter une validation côté ça Pour la rajouter, on va d'abord récupérer la valeur de mon formulaire côté serveur de remix dans mon axe.

03:46 Pour cela je vais quitter cet objet que je reçois de ma méthode et je vais le taper en action function arge et je vais l'emporter depuis remix run -no. Maintenant je vais récupérer la propriété request et depuis ma request j'aimerais récupérer la propriété form data. C'est une méthode qui est sous forme de promesse et je vais la récupérer dans une variable que je vais appeler formdata est égal à request. Formdata. Et cette formdata, c'est ce qu'on peut déjà voir dans notre requête ici.

04:14 Et je soumets à nouveau le formulaire je clique dessus et dans le pilote on peut voir que j'ai un forme data avec une valeur et une clé comme mon côté client j'ai donné un nom à mon input et j'ai donné le nom name côté serveur. Pour retrouver cette valeur, je vais devoir chercher la clé name. Donc je vais faire un farm data get entre parenthèses le nom de la clé la clé s'appelle name et je vais sauvegarder ce name dans une variable. On peut voir si je mets le survol sur mon name que c'est soit en forme data and 3 value soit nul. C'est-à-dire la valeur peut soit être nulle, s'il n'y a pas de clé, soit en forme data and thri value.

04:47 Le form data and thri value peut soit être un string, ce qui est le cas, soit un fichier. Effectivement avec les formulaires, il est possible d'envoyer tout type de fichiers comme des images ou des pdf à notre serveur. Je vais donc faire un console log de ma propriété name. Maintenant, je vais retaper Virgile et je soumets le formulaire et on peut voir que ça a été console logé. Si j'ouvre mon terminal, on peut voir le console log name double point verger.

05:09 Et ce console log vient directement du cerveau. J'ai bien reçu ma donnée de formulaire côté cerveau grâce à mon acte et je renvoie nul pour le moment. Mais plus tard dans la vidéo, on va envoyer un message de succès, par exemple formulaire bien envoyé ou une erreur ces produits veuillez réessayer. Maintenant je vais rajouter un deuxième champ et je vais l'appeler email et ça sera plus un type texte ça sera un type email. Je vais donc retirer le props milllem's et je vais rajouter un petit peu de style à mon formulaire pour que ça soit un peu plus lisse.

05:35 On peut également rajouter un label autour de chacun de nos formulaires avec une description de la propriété. On va mettre email et non. Super, c'est vraiment beau. Maintenant le type email, c'est déjà une sorte de validation pour nous, côté client. Par exemple, si ici je rajoute un champ qui n'est pas un email et que je remets mon prénom, là on peut voir qu'il me demande d'inclure un arobase.

05:56 Le problème c'est que si j'inclus juste un arobase et une lettre à la suite aussi simple que ça exemple b arobase a et que je le soumets, le formulaire fonctionne. Mais l'e-mail est forcément valide, on le sait très bien, il devrait y avoir un point f r, un point com. Donc on a besoin de rajouter une validation côté serveur pour valider l'email, par exemple avec une Rejet. Donc je me rends côté serveur et je vais récupérer l'email form data et la clé email on va d'abord commencer par le console loguer si je renvoie mon formulaire on peut voir que le console log a changé j'ouvre mon terminal on voit toujours le console log donc je récupère bien mes données côté serveur c'est très bien vous avez compris l'idée mais en gros j'aimerais afficher un message d'erreur juste en dessous par exemple ici votre email est invalide et on va le mettre en rouge et j'aimerais que ça me dise en dessous du champ votre email est invalide mais seulement si mon email est invalide et ça sera la validation côté serveur. Ça apparaîtrait de cette manière mais seulement si l'e-mail est invalide.

06:49 Et pour ce faire côté serveur, on pourra rajouter par exemple une variable qui se valide qui est un booléen. On va dire qu'un email valide, c'est égal virgile ragomax. Fr et maintenant, on le renvoie sous forme d'objet juste en renvoyant un objet ou alors on peut aussi utiliser la méthode json qu'on importe de péril maintenant je récupère le contenu de mon action donc la réponse de mon action côté serveur dans le client en utilisant le hook qui s'appelle use action data. Et je l'emporte depuis remix trend tiret réel et je vais rajouter le site générique qui est ce que me renvoie mon action, c'est-à-dire type of en un mot action. Maintenant on peut voir que data peut soit être une des fans, soit contenir un is valide et un booléen.

07:28 Donc je vais rajouter conditionnement mon affichage. Si data point is valide égal à false alors j'affiche ce span en rouge sinon je n'affiche rien. On peut voir qu'un email valide c'est un email qui est égal à vergile arobase algo max. Donc je viens m'appeler Virgile et je vais mettre l'email valide Virgile arobase rgo max point fr. J'envoie le formulaire et il ne s'est rien passé.

07:49 Si par contre je change mon email je mets virgile arobase algo point f r, je soumets et là on a le message d'erreur en rouge. Le problème, c'est qu'on doit coder toute la logique de validation à la main et ça prend un temps fou. De plus, notre html va devenir illisible. Regardez, rien que maintenant, on a un div, notre label, notre spam, afficher conditionnellement. Et si on a plusieurs méthodes de validation, on ne va vraiment pas s'en sortir, surtout si on a des grands formulaires avec dix propriétés.

08:15 Mais on va utiliser deux outils. Le premier, ça va être la librairie Zod et Zod va nous permettre de définir un schéma de cette manière. Par exemple, notre schéma d'utilisateur qui sera sous forme d'objet avec un name qui sera un string et un email. Donc, je vais installer Zod dans mon projet. J'ouvre mon terminal et je fais un npm install de Zod.

08:34 Maintenant, je peux fermer le terminal et je vais importer z depuis la librairie zod. Juste au-dessus de mon action, je vais créer mon schéma et je vais mettre mon schéma est égal à zod point objet qui contient une propriété name qui est un string donc on va mettre z string et une propriété email qui est un email mais pour le moment on va mettre z Maintenant, nous avons notre forme data et notre forme data, ce n'est pas vraiment un objet et on a envie de le transformer en objet pour le valider avec Zot. Pour transformer un form data en objet, on peut utiliser la méthode objet. Fromentres, c'est-à-dire qu'on va transformer ces entrées de notre forme data en objet je vais donc passer en forme data et je vais récupérer mon objet et maintenant on va faire un console log de cet objet pour être sûr que ça a bien fonctionné je retourne sur mon application et il ne faut pas oublier de relancer le projet avec un p m rundev. Maintenant on envoie un email et un nom.

09:26 Je soumets le formulaire et on peut voir qu'on a bien un console log objet qui contient un email et un nom. Donc on a transformé notre forme data en objet. Maintenant qu'on a transformé notre forme data en objet, on peut supprimer tout ça et faire un pas. C'est-à-dire qu'on peut récupérer notre donnée en faisant un schéma qui est le schéma qu'on a défini tout en haut avec zone. Parse de notre objet.

09:45 Et si ce parse a fonctionné, on pouvoir que data va contenir deux clés name et email. Maintenant je vais pouvoir les déstructurer ici pour récupérer mon email et je pourrais toujours en seul log l'email pour être sûr que rien n'a changé. Je soumets le formulaire et on voit bien que ça a catalogué mon email. Si maintenant je change mon email et que je soumets, on a toujours le message d'erreur. Sauf que cette fois, on a utilisé Zod pour partielle les données avec notre schéma.

10:09 Donc on bénéficie des types grâce à TabTrip. Ici, je sais que je possède une propriété name dans mon schéma et c'est véridique. Elle existe, c'est sûr, parce que si elle n'existe pas, ça va être trop une erreur. On va faire le test. Si par exemple, au lieu de name mon input, je vais mettre page, que j'utilise la page et que je renvoie ma donnée, je soumets le formulaire.

10:27 Sauf que là, on a une erreur de z parce qu'il s'attendait à retrouver la propriété name mais qu'on a changé le nom de la propriété. Donc il faut faire très attention à ça quand on fait un parse avec ZAD. Mais nous ça va pas s'arrêter là ça va être encore plus incroyable que ça. C'est-à-dire ici pour le name, je vais rajouter un message pour signifier que le name est requis et je vais mettre votre nom et ensuite les mails je vais rajouter un message requis d'un require d'erreur en argument et ça sera votre email est requis mais on ne va pas s'arrêter. Pour l'e-mail, je vais rajouter à la suite un deuxième type de validation et je vais mettre aussi un type email et je vais mettre un message de type votre email doit être un format valide.

11:04 Et pour mon name, je vais rajouter un min pour dire que je m'attends à recevoir minimum trois caractères donc pas un nom à deux caractères avec un objet et comme message votre nom doit faire au moins trois caractères. Maintenant que j'ai rajouté cette validation côté on va retenter une validation. Ici je vais remettre un vrai mail et un vrai prénom. Je soumets le formulaire et on n'a aucun problème. Par contre, si je mets un email faux et que je soumets le formulaire, on voit que Zod a déclenché une erreur côté serveur.

11:32 Mais nous, on n'a pas envie de la gérer. C'est-à-dire si Zod déclenche une erreur côté serveur, on a envie d'afficher votre email doit être au format valide. Et en fait, au début, on affichait ici, c'est-à-dire dans le spam, votre email est invalide et c'est ce que nous allons faire tout de suite. Pour cela, nous allons installer la librairie conforme. On peut retrouver sur le site conforme point guide.

11:50 Et ça va se passer à peu près comme sur cet exemple-là. C'est-à-dire, on va devoir importer un nouveau hook qui s'appelle use form et une méthode pour passer avec Zod qui s'appelle parse with thed. Ensuite, nous allons définir notre schéma puis dans notre action, nous allons récupérer notre forme data et nous allons le parse avec Zod en lui donnant notre schéma et nous récupérons un objet submission. Ensuite, si submission n'a pas réussi, alors on renvoie un message d'erreur côté client. Sinon, c'est bon.

12:18 Ça veut dire que la validation est passée. Ensuite, dans le composant côté client, on va utiliser le hook use form en passant notre schéma comme argument. Et puis ici, dans notre formulaire, on va rajouter donc notre label, notre input et les erreurs éventuelles de notre formulaire. Alors c'est parti, je clique sur getting started, sur tutoriel, je vais copier mpm install arobase conforme ou react conforme to zod et je vais sauvegarder. J'ouvre maintenant mon terminal, je pile mon projet, je lance cette commande pour installer ces deux librairies, on peut relancer le projet avec un entermerondev et maintenant je vais dans mon index.

12:51 Je vais utiliser le haut use form. Qu'on importe depuis conforme to réac et je vais lui donner quelques arguments déjà je vais lui donner une string et ça c'est pas nécessaire mais ça permet de gérer la validation côté client va nous permettre de dire qu'on veut utiliser ce schéma zod avec cette validation le type email la longueur minimum à trois côté client dans notre formulaire donc on va mettre comme constaint notre schéma zot mais pour ce faire on va faire un get zot constraint pour récupérer une contrainte avec un formulaire zot on va donc rajouter notre schéma zot on a déclaré tout en haut ensuite le deuxième champ sera le last resolve et pour le moment il est une des fans le last resolve c'est la dernière validation qui a été faite côté serveur C'est-à-dire ici dans notre data ou plutôt dans l'attraction, nous allons traiter et valider le formulaire côté serveur, puis nous allons renvoyer ce résultat côté. Enfin on va utiliser la méthode on validate de cette manière et nous allons déstructurer l'objet form data qui est exactement le même forme data que celui qu'on récupère côté serveur et nous allons le parser.

13:50 On va le parser avec la méthode parse with zone qui est à peu près pareil que le schéma prend parse, sauf que ça ne va pas déclencher l'erreur. Ça prend comme premier argument en forme data et comme deuxième argument, un objet avec comme schéma notre schéma. C'est-à-dire que rien qu'au côté client, on utilise notre schéma à deux endroits pour la constaint, donc pour valider chaque input d'un formulaire et à la validation. On peut voir qu'on a plein d'autres paramètres par exemple à quel moment est-ce qu'on veut la validation soit effectuée. On peut choisir de valider à chaque input mais pour le moment, on va choisir de valider seulement lors de la soumission du formulaire.

14:24 Maintenant, ce Hook me renvoie deux valeurs. Il me renvoie le formulaire et il me renvoie chacun des champs de mon formulaire sous forme d'un tableau. Donc la première chose qu'on va faire, c'est récupérer ce formulaire et nous allons spread les props parce que Conform a besoin d'assigner des props à notre formulaire, voire le gérer et le valider un peu mieux. C'est-à-dire il va vouloir le focus, vouloir sa référence, son ID. Donc on va utiliser la méthode getform props et on va passer comme argument notre formule la méthode get form props a été importé depuis conforme to real maintenant ici on a notre une photo et on va pouvoir tout retirer pour ne laisser plus rien à part des propres on va appeler get input propre et ça prendra comme argument mon fils qui était le deuxième deuxième valeur de mon look forme field point et là je vais mettre que c'est mon email ensuite je vais rajouter un objet une deuxième argument et ça sera le type et on peut mettre aussi un type email.

15:17 Maintenant on va faire comme dans la documentation ici c'est à dire qu'on va afficher les erreurs dans un deal. Au lieu d'afficher notre erreur en dur on va mettre field point email point erreur et on va même commenter notre nom pour le moment on va tester cette méthode comme ça Je vais retirer la valeur name pour que ça soit encore plus simple. Je retourne dans mon projet et je vais faire une soumission de formulaire. On va tester. Je vais taper un email faux, je vais mettre AAAAAAA, je vais faire soumettre et là on peut voir qu'on a une validation côté client.

15:44 Votre email doit être au format valide. C'est super cool, c'est mon message d'erreur et je vais le mettre en rouge. Si maintenant j'envoie un email valide et que je soumets, peut se mettre plusieurs fois, là on peut voir que ça m'a bien fait les consoles log et que ça ne m'a pas renvoyé d'erreur donc c'est super ça fonctionne à merveille maintenant on a envie de faire cette validation côté serveur parce que on ne valide pas encore côté serveur. Donc une fois après avoir récupéré le form data, si on retourne sur la documentation de conforme, on peut voir qu'on récupère un objet submission et qu'on utilise la méthode par swiss donne et si on n'a pas un statut succès, on envoie une réponse donc une replay. Je vais donc supprimer ces trois lignes et je vais copier le code de cette documentation.

16:22 Pareil pour la méthode parce que z on a besoin de fournir notre schéma, zod va s'occuper du reste et ensuite si on n'a pas un succès, alors on va renvoyer un sub-mission. Play. On va l'envoyer dans le json pour être plus cohérent et on va appeler ça un resel. Ensuite si ça a fonctionné alors nous avons des données dans sadmition point value et on peut voir que notre seule mission point value contient une propriété email et ça c'est la propriété a été par ces parts donc je peux récupérer comme ceux ci mon email depuis sa mission en value et je suis sûr il a été par c'est parce que sinon une réponse négative aurait été envoyée aux côtés clients. Maintenant, on peut encore une fois s'inspirer de la documentation et on peut mettre que cet email est valide.

17:01 Ça demande s'il est égal à virgile arobase algo max point f r. Donc on va rajouter cette condition-là. Si ce n'est pas valide, donc si ce n'est pas égal à virgile, alors au lieu de renvoyer mon is valide, je vais renvoyer une réponse qui va s'appeler l'e-mail et un valide et ça ça sera directement une erreur de formulaire on va faire comme au dessus va renvoyer du json avec une clé reisle donc je vais faire ce rifecto et si tout est valide au lieu de renvoyer il se valide on va faire exactement la même chose on va renvoyer une clé avec un replay. Maintenant, si je retourne côté client dans mon data, on peut voir que mon data possède une clé resolve à chaque soumission de formulaire et on va le mettre ici dans last resolve. Je vais donc mettre que last resolve est égal à data point d'interrogation parce que cette valeur n'est définie que après la soumission du formulaire résonne.

17:45 J'actualise maintenant ma page et je vais envoyer un email en valide. Ah ah ah ah ah ah ah soumettre votre email doit être au format valide. Ça, c'est une première erreur que j'ai. Maintenant, si je mets un email qui est valide en théorie avec le shimazod, mais qui n'est pas égal à virgin arobase et que je soumets le mail, on peut voir qu'on n'a pas l'erreur d'afficher, mais ça c'est de notre faute en fait on a besoin de l'afficher tout en bas de notre formulaire ça sera donc un form point error on va rajouter ici et là l'erreur vient d'être affichée l'email est invalé. Ça veut dire que la validation n'a pas été effectuée avec Zod parce que j'ai rajouté une condition supplémentaire.

18:20 Et ce qui est bien avec cette condition supplémentaire, c'est qu'on préserve l'état de notre formulaire. C'est-à-dire que l'utilisateur ne doit pas rentrer toutes les informations si jamais il a fait une faute. Maintenant que c'est fait, on va modifier notre schéma, on va récupérer notre propriété name et on va la rajouter. Ici donc je vais copier ce composant là, je vais l'appeler name et cette fois dans get input propre, on va prendre comme champ name et ça aura comme type du texte et l'erreur sera depuis field point name point erreur vous voyez je viens de rajouter un champ name côté client dans mon schéma et il est disponible à l'autocompletion dans mes inputs. Et si je retourne côté serveur, je pourrais maintenant le déstructurer.

18:59 Et ça, c'est grâce à zod et conforme qui me permettent de gérer mes formulaires de manière full stack. Si demain on retire la propriété email, c'est très simple, on la retire et là on aura une erreur ici parce que la propriété email n'existe pas. On aura une erreur ici parce que le champ email n'existe plus et Typescript ne sera pas du tout content. Je vais remettre mon email, mon nom et je vais même enlever cette validation supplémentaire avec is verger. On va juste faire un console log des données pour s'assurer que ça fonctionne bien.

19:27 Maintenant je vais donc envoyer un email valide, un prénom valide, je soumets le formulaire, ça fonctionne très bien. Mais ce qui est cool, c'est qu'on peut aller encore plus loin et qu'on peut même faire de l'asynchrone. C'est-à-dire qu'on peut contacter carrément notre serveur pour voir si l'email existe déjà côté serveur et s'il existe déjà, alors on ne va pas le créer. Mais alors comment faire Donc je vais vous montrer tout de suite avec une API externe. Si cette vidéo t'a été utile, n'hésite pas à t'abonner à la chaîne de pour être prévenu qu'on en sort une nouvelle.

19:54 Tu peux également laisser un commentaire en bas de cette vidéo pour en faire des retours, des suggestions ou même poser tes questions. On va utiliser json play soler. Je vais sur json play soler et je vais dans mon champ users. On va dire que c'est notre base de données, on a donc une liste d'utilisateurs et je vais d'abord la récupérer. Pour la récupérer, je vais créer un nouveau fichier dans mon dossier app que je vais appeler serveur t as.

20:16 Dedans, je vais copier mon url et je vais exporter une méthode que je vais appeler get users qui fera un de cette url on va pas oublier de préciser que dans nos nous avons un compte de application slash json c'est le type de contenu que nous recevons c'est bien du json et on reçoit une donnée en retour on va awaite notre fait et on va mettre que cette méthode est asynchrone Donc là je récupère des données d'une API externe, donc on fait un traitement asynchrone. Ensuite on va créer un petit schéma zod, user qui m'a égal à zod point object nous ce qui nous intéresse c'est juste une idée number un email de type z string et pourquoi pas le name de type z maintenant on va mettre notre tableau user c'est un z en arrêt donc un tableau de user on va transformer notre data en json avec un awai data en json on va renvoyer au client notre data sous forme de JSON mais par C avec ça. Je la renvoie en faisant un users climat, on peut voir qu'après avoir fait notre méthode get users est une promesse d'un tableau d'utilisateur. Et c'est très bien parce qu'on va vérifier que notre email n'existe pas dans cette base de données.

21:19 Pour être vraiment sûr, je vais rajouter une méthode l'odeur afficher cette donnée côté client. Donc je crée une méthode l'odeur et je vais renvoyer ma méthode get users nous allons avouer maintenant que j'ai rajouté ce l'odeur je vais utiliser le use l'odeur data qui hérite du type type off de la méthode l'odeur que je viens de créer et ça me renvoie un tableau d'utilisateurs déjà existe maintenant en dessous de mon formulaire j'ai envie de boucler de faire une liste sur mes utilisateurs vous en apprendre map on va afficher leur email et on va rajouter une clé. Si maintenant je retourne côté client, on peut voir que j'ai une liste d'emails et on va dire que c'est tous les utilisateurs présents dans ma base de données. Donc maintenant, si je me crée un email avec cette adresse là, Leanne, et que je fais une soumission, ça ne devrait pas me faire un console. Ça devrait me dire, l'e-mail existe déjà.

22:04 Mais alors, comment faire Ici, nous effectuons notre part avec notre schéma. Mais notre schéma, nous pouvons l'améliorer ou l'augmenter côté cerveau. C'est-à-dire qu'il est déclaré ici en dehors de ma méthode action. Donc il sera utilisé tel quel côté client dans le hook form, mais côté serveur avant de l'utiliser, je peux faire un super reefine qui est une méthode de Zod et ce super refine va me permettre de raffiner le schéma ou de rajouter des propriétés de validation. Je vais vous montrer.

22:33 Ce super refine récupère donc la donnée du formulaire et le contexte de zone. Comme il récupère la donnée du formulaire après qu'elle ait été par c'est donc une fois que ces deux valeurs sont correctes, il déclenche le super refine je peux les récupérer en les déstructurant depuis mon objet date et c'est ici que je vais rajouter cette logique Alors comment faire J'ai besoin de récupérer ma liste d'utilisateurs en base de données et voir si l'un de ces utilisateurs possède les mails que j'ai rentré. Donc est-ce que l'utilisateur existe Donc je vais utiliser cette méthode exactement la même. Je vais récupérer la liste des utilisateurs en faisant un out. Comme c'est un await, je vais devoir mettre cette méthode et comme cette méthode est await, on va devoir rajouter en dessous d'un autre objet de configuration par swissod, le mode clé à signe.

23:15 Et comme c'est égal à true, nous allons également faire un await sur notre méthode par swissod. Donc nous allons faire de la validation asynchrone de nos données de formule maintenant que j'ai cette liste d'utilisateurs on va voir s'il existe et on va utiliser donc on va boucler sur notre tableau d'utilisateurs on va faire un somme user et si l'un des emails de nos utilisateurs est égal à notre email alors ça veut dire que l'utilisateur existe déjà. On va appeler cette méthode already existe. Maintenant, on peut conditionneralement rajouter if already existe. Alors là, nous allons exécuter notre et nous allons rajouter une issue, donc une erreur qui prendra plusieurs arguments ça va prendre un code le code c'est custom par défaut on rajoute une erreur en plus personnalisé ça va prendre un chemin le chemin c'est simplement pour savoir lequel des deux inputs a une erreur pour nous c'est l'erreur et pour nous le chemin c'est l'e-mail parce que l'erreur a été effectuée sur l'e-mail Donc comme chemin nous allons mettre email sous forme de tableau et enfin on peut rajouter un message et le message fera l'e-mail existe déjà.

24:13 Maintenant si on veut dévoiler l'identité de la personne écrit cette mail, on peut faire une petite rifacto, on va faire un existe in user et au lieu de faire un thumb, on va faire un find pour trouver l'utilisateur s'il existe. Et ce code revient exactement au même sauf que si on dit qu'il existe on peut donc utiliser ces données email existe déjà on va l'appeler email est utilisé l'utilisateur. Là je vais mettre le nom de l'utilisateur mail. Moi je vais utiliser ma page, je vais rajouter mon nom, je vais soumettre et ça va fonctionner. On peut voir le console log, on n'a aucune erreur.

24:43 Par contre si j'utilise l'e-mail de Nathan, ici je vais soumettre, je vais mettre comme nom, je m'appelle Nathan, là j'ai une erreur. L'e-mail est utilisé par l'utilisateur Clémentine Bosch. Et si on va dans JZAN Play Soller et qu'on regarde les mails de Nathan, on peut voir que son c'est vraiment Clémentine Bosch, mais elle a utilisé l'email de Nathan. Et c'est vraiment incroyable parce qu'on a transformé notre schéma ZOD en schéma asynchrone on a rajouté une étape de validation donc on a appelé une api externe json ps solder juste après la soumission de notre formulaire et on peut faire ça avec tout On peut faire une médiation stripe, on peut faire une médiation Google, on peut appeler plusieurs bases de données. Ce qui est bien avec cette méthode, c'est que quand je fais une soumission du formulaire, on peut voir là, on a le focus management c'est-à-dire l'erreur est survenue sur l'e-mail donc l'e-mail il a été focus il a été sélectionné et mon navigateur sait que je suis actuellement sur cette mail là.

25:34 Là, je peux de nouveau le modifier maintenant, je peux tout de suite corriger mon erreur. Maintenant, il y a une dernière chose que j'aimerais vous montrer avec ZAD, c'est la possibilité de pouvoir reset le formulaire si le traitement a réussi. Donc si le traitement a réussi, nous allons dans notre objet replay rajouter un objet et on va mettre un reset forme à trous. Tout aussi simple que ça, maintenant j'utilise la page, j'utilise un email qui existe déjà et si l'email existe déjà, on ne va pas réinitialiser le formulaire. On a envie que l'utilisateur connaisse l'erreur qu'il a faite je vais m'appeler Julian je soumets là on peut voir mon erreur asynchrone l'e-mail est utilisé par l'utilisateur patricia par contre si j'utilise Virgile arobase alco max et que je soumets là, le formulaire a été reset, ce qui veut dire que nos utilisateurs ne vont pas re-remplir les champs.

26:14 Il a été reset, il a réussi, on a sauvegardé cette utilisateur en base de données on a fait n'importe quel traitement inscrire newsletter tout ce que vous voulez en tout cas je suis vraiment ravi d'avoir découvert cette nouvelle manière de gérer mes formulaires l'application Remy et voilà on a terminé pour cette vidéo sur les formulaires avec remix et la gestion des erreurs j'espère que ça vous a plu. N'hésitez pas à vous abonner à la chaîne pour nous soutenir, ça nous fait vraiment plaisir. On prévoit de sortir encore plein de contenus sur le framework. Je vous souhaite une très bonne journée et on se retrouve très bientôt pour une vidéo Reynid. À plus.