En utilisant le nouveau type React.FC sur votre projet existant, vous pouvez rencontrer l'erreur suivante :

Property ‘children’ does not exist on type <YourCustomTypeProps>

Cela parce que la signature du type à changé dans les versions récentes de React !

Pourquoi la signature de React.FC à changé ?

La propriété children a été retirée du type React.FunctionComponent (React.FC) on va donc devoir la déclarer explicitement dans nos propre propriétés.

TLDR; Cela permet de prévenir les bugs comme celui-ci :

Ainsi, vous pouvez être certain que le composant que vous utilisez prend en charge les enfants, et améliorer votre base de code/qualité.

Comment utiliser React.FC et la prop children dans React 18+ ?

Dans les versions précédentes la propriété children était déjà définie en tant que propriété optionnelle dans le type React.FC.

Dans les versions récentes, cela à été supprimé. Maintenant il faut désormais spécifier explicitement la propriété selon notre besoin. Elle peut être requise ou optionnelle selon les besoins de notre logique métier.

Que faire si je souhaite conserver l'ancien comportement de React.FC et de la propriété children ?

Il est possible de surcharger les types de React en créant un fichier de définition personnalisé. Cela peut être un fichier de définition global que l'on utilise déjà dans le projet ou alors il est possible d'en créer un nouveau avec un nom arbitraire comme react.d.ts tant qu'il se trouve dans le périmètre de compilation TypeScript.

La définition suivante rétabliera le comportement équivalent aux type de @types/react version 17.

Il ne reste plus qu'à profiter de notre forte définition de type ;)

Comment faire pour typer avec TypeScript les composants enfants d'un composant personnalisé avec React18.

Comment typer la prop children de React.FC dans React 18 avec Typescript ?

Dans certains cas on défini un type TypeScript regroupant plusieurs types d'évènements et leur variables associées. Ou parfois c'est juste un type d'objet et la données associée.

Par exemple on pourrait définir une liste de types de cartes à afficher sur une page d'accueil d'une application mobile.

Chacune des carte ayant des données spécifiques à son type.

L'interface définissant cela pourrait être la suivante :

À partir d'ici je souhaite throw une erreur si jamais l'évènement traité par mon code n'est pas celui que j'attends j'écrirais généralement le code. Concrètement dans un bloc de code cela pourrait se représenter de la sorte :

Problème, cela commence à devenir un petit peu verbeux et on se rend bien compte que l'on à tendance à répéter le même code avec le throw.

Comment faire pour extrait ce morceau de code et continuer de profiter de la sécurisation du type ?

Cette fonction a maintenant un paramètre de type générique T qui est contraint par l'union des propriétés de type dans TimelineCardsType (Types Génériques).

La valeur de retour est asserts element is ce qui signifie qu'une exception doit être levée si l'élément (la carte) n'est pas du type indiqué. (Fonctions d'assertion).

TimelineCardsType & { type : T } signifie que l'union de tous les éléments est filtrée pour ne retenir que ceux qui correspondent au type passé en tant que expectedType. (Types d'intersection)

Désormais, cette fonction fonctionne sans problème et de cette manière on économise/factorise quelques lignes ;)

Utiliser des gardiens de types personnalisés permet de factoriser son code tout en s'assurant de la cohérence des types.

Asserts Typescript Guard pour gérer des types d'éléments

Lorsque l'on utilise TypeScript avec ReactJS il arrive souvent que l'on souhaite passer en tant que props un composant non instancié. Comment ça marche ? Pour cela il faut définir son type.

L'utilisation de React.ComponentType<P> est la bonne méthode. 

Ce type est adapté pour accepter un composant de classe (React.ComponentClass<P>) ou un composant de fonction (React.FunctionComponent<P> alias React.FC<P>) qui prend des props définies par l'interface P.

React.ReactNode et React.ReactElement sont les types pour le JSX retourné par le composant - pas pour un composant appelable, c'est-à-dire non instancié par le JSX ou createElement

Il n'est pas recommandé d'utiliser <unknown> en tant que type générique pour les props du composant. Seulement si le composant n'utilise pas de props et que le type {} génère un warning dans votre configuration

Il faut déclarer que le composant nécessite uniquement les props que l'on fournira lorsque l'on instanciera le composant avec React.createElement(Comp) (ou la syntaxe JSX équivalente <Comp/>).

Dans ce cas là il n'y a pas de props attendues, donc ce serait React.ComponentType

On obtient une erreur si on appele Comp sans fournir someKey ! On n'obtient pas cette erreur en appelant React.createElement(Comp) car pour une raison obscure, l'argument props est facultatif.

Une technique simple pour le typage des props d'un composant qui accepte un composant en tant que props.

TypeScript React : Comment typer les props pour recevoir un composant en tant que props ?

La méthode originelle consiste à faire glisser l'archive .ipa dans Apple Music. C'est un peu répétitif et surtout sur android on peut taper adb install <chemin_apk>

Sur IOS on peut installer sur son Macbook ideviceinstaller

Ensuite il suffit de brancher son téléphone et de lancer la commande suivante

Comment installer une archive iOS App Store Package (.IPA) en utilisant l'interface en ligne de commande.

Vous souhaitez implémenter une connexion OAuth2 avec Facebook et expo.io ? Vous êtes au bon endroit !

Les APIs d'authentification OAUth2 pour Facebook et Google étant maintenant dépréciées, Expo nous invite à utiliser la nouvelle implémentation à base du Web Browser nommée expo-auth-session.

Cependant, force est de constater que cela ne marche pas encore très bien dans tous les contextes.

En effet quand vous utilisez Expo GO le client pré-compilé pour Expo cela fonctionne plutôt bien mais dès que l'on créé une app Standalone  cela peut vite se compliquer, principalement sur Android et on fini par s'arracher les cheveux.

Plusieurs topics sont d'ailleurs à l'heure où j'écris cette article entrain de signaler divers problèmes liés à expo-auth-session (SDK44 Expo)

https://github.com/expo/expo/issues/13714

https://github.com/expo/expo/issues/17011

https://github.com/expo/expo/issues/13513

Après moultes recherches et expérimentations j'en suis arrivé à trouver une solution plutôt correcte qui corrige deux problèmes, afin d'avoir un login Facebook fonctionnel sur IOS et Android en Workflow Managed pour des applications créés avec eas-build en standalone ou expo-dev-client.

Mais avant voyons un peu plus en détail le fonctionnement de expo-auth-session.

expo-auth-session est une librarie qui a vocation à nous simplifier la vie pour une autorisation OAuth2 avec divers fournisseurs supportés, parmis lesquels Google et Facebook.

Elle fournie des primitives via une API simple qui va entre-autres permettre d'ouvrir un navigateur dans notre application qui utilise les cookies du navigateur système (afin de profiter du fait que l'on est peut-être déjà connecté au service en question). 

Une fois que l'utilisateur valide les permissions la librairie va gérer la redirection du service tier et traiter les données de retour afin de récupérer un jeton d'authentification, un ID utilisateur et tout ce qui pourrait nous servir dans le cadre d'une démarche de connexion OAuth2. Avec ce jeton d'authentification on peut ensuite consommer une API tierce afin de récupérer des données client.

Comme on l'a vu c'est pratique et sur Expo GO ça marche plutôt bien, par contre sur une application standalone qui n'a pas toute la configuration au milimètre comme dans Expo GO, c'est parfois plus compliqué, notamment sur Android.

Pas de panique : ci-dessous un workflow fonctionnel et très simple à implémenter.

Un workflow expo-auth-session complet et fonctionnel avec Facebook pour ExpoGO ET Android/IOS standalone (EAS BUILD)

Testé sur expo SDK 44 avec les packages suivants :

expo install expo-auth-session expo-random

2 - Définir un scheme pour le deeplinking vers son app.

3 - Configurer l'application Facebook Developer

Aller dans la configuration de son application Facebook (en créer une si on en n'en pas) et dans la section Facebook Login mettre l'URL vers le expo auth link. 

Cette URL est construite en deux parties https://auth.expo.io/ et votre originalFullName qui est la sommes du username et du slug de l'app.

Pour récupérer votre originalFullName vous pouvez utiliser la commande suivante dans le dossier root de votre projet :

expo config --type public | grep "originalFullName"

Ensuite on vérifie qu'on est bien dans cet état et on valide !

Maintenant on passe à la meilleure partie…

La première chose à noter est qu'on a un bug sur EAS build actuellement et qui ne sera peut-être plus d'actualité au moment où vous lirez cet article (n'hésitez pas à me MP pour me le signaler si tel est le cas).

Pour cela il faut surcharger le originalFullName comme ci-dessous, quelques part au démarrage de l'app, sans quoi on aura une erreur à l'utilisation de useProxy: true. Vous pouvez consulter les topics en début d'article pour suivre l'avancement sur ces bugs.

Le deuxième problème est un problème de redirections qui ne marche pas et qui font soit crash l'app, soit d'autres comportements étranges et qui juste ne marche pas.

Ici la solution consiste à toujours utiliser les liens auth.expo.io qui ont plusieurs bénéfices

pour se faire il faut combiner useProxy: true et une redirectURL définie à la main qui va générer le lien en auth.expo.io TOUT LE TEMPS.

On récupère ensuite le jeton d'authentification dans la variable response, qui nous permet par exemple d'interroger l'API Facebook.

https://graph.facebook.com/me?fields=first_name,last_name,email,picture.type(large)&access_token=${response.authentication.accessToken}

And VOILÀ avec tout cela vous devriez être tranquille en attendant que Expo démocratise un peu l'utilisation de ce module.

Pour implémenter une authentification OAuth2 via Facebook avec Expo qui marche sur toutes les plateformes et dans tous les modes ! Ce qui n'est pas le cas pour la configuration par défaut.

Utiliser expo-auth-session via Facebook (Expo Managed Workflow | Expo GO/Standalone app/expo-dev-client | EAS BUILD)

XState est une bibliothèque permettant de créer, d'interpréter et d'exécuter des machines à états finis et des diagrammes d'états, ainsi que de gérer les invocations de ces machines en tant qu'acteurs. Les concepts informatiques fondamentaux suivants sont importants pour savoir comment faire le meilleur usage de XState, et en général pour tous vos projets logiciels actuels et futurs.

Cela tombe bien car lorsque nous avons réalisé Jerry, l'application de blagues qui vous propose de rire entre amis nous avons eu besoin de gérer des transitions d'états pour gérer les différentes phases qui s'enchainent pour le jeu.

Dans cet article nous allons détailler comment ont été modélisés les états et les transitions entre les 3 phases de jeu d'une des premières version de Jerry :

Le lancement d'une chronomètre où il ne faut pas rire

Comme nous le suggère la méthodologie pour déterminer une machine à état commençons par définir la liste des états, les évènements (permettant de déclencher les transitions) et l'état initial.

La définition de l'état de notre machine

choose_joke : L'état dans lequel on tire au hasard une blague.

timer_running : L'état dans lequel le décompte de temps est affiché

choose_loser : L'état dans lequel on choisit si quelqu'un à rigolé à la plaisanterie et qui déclenchera le gain d'un point pour l'équipe gagnante !

Et le contexte, qui sont des variables sur lesquelles on peut agir, parfois aussi nommé état, mais au sens plus large.

current_joke nous permet de récupérer une chaine de caractères qui représente notre blague actuelle, color sert à donner la couleur de fond utilisée pour afficher la blague, celle-ci est tirée aléatoirement à chaque cycle et enfin teams_score sert à définir l'avatar de chaque équipe ainsi que le nombre de points dans la partie.

La définition des évènements de notre machine

GET_NEW_JOKE : Est un évènement qui permet de tirer une nouvelle blague

START_TIMER : Est un évènement qui permet de démarrer le décompte de temps

SELECT_WINNER : Est un évènement qui permet d'indiquer le gagnant du duel en cours.

Commençons par partager le code de notre machine et expliquons chaque éléments les uns après les autres.

Le truc bien avec XState c'est que l'on peut utiliser le vizualizer pour récupérer un diagramme représentant les états et transitions de notre machine. Pour le code ci-dessus, voici le diagramme obtenu.

Pour plus de détails et de contrôle  il est possible de suivre ce lien pour consulter le diagramme en détails.

Explication des parties de notre machine à états

Tout d'abord on définit deux interfaces Typescript qui nous servirons à définir d'une part le contexte (équivalent de l'état qui peut changer) de notre machine, comme vu plus haut, mais également les évènements qui permettront de déclencher les transitions, grâce à cela on obtient un typage sécurisé en utilisant la généricité de la méthode createMachine.

Ensuite, on continue en donnant un identifiant à la machine avec la clé id, cela sert à des fins de debug. Un état initial, dans notre cas choose_joke et un contexte par défaut qui sera probablement surchargé afin que l'on puisse injecter de la donnée.

S'en suit la définition de nos différents états, commençons par choose_joke

On voit ici que plusieurs hooks sont définis :

entry : permet de définir une action à exécuter à l'entrée dans l'état choose_joke. Dans notre cas on fait appel à une fonction getRandomBackgroundColor qui nous permettra de changer le contexte avec une nouvelle couleur. Cette fonction est définie par défaut dans le second argument de notre méthode createMachine, à savoir la configuration, qui notons-le peut être surcharger au moment ou nous allons exécuter notre machine. Ici rien de sorcier, on utilise lodash pour tirer aléatoirement une couleur de fond d'écran, puis on utilise la méthode assign de XState pour fusionner la donnée dans le contexte actuel de la machine.

Ensuite nous avons invoke, ce qu'on appelle un service dans XState. 

id permet de cibler ce service plus tard et de mieux le repérer dans le générateur de diagramme.

src permet d'indiquer la fonction qui retourne une promesse à exécuter dans le cadre de ce service, ici pour un meilleur debug et une meilleur visualisation on utilise encore une référence textuelle à une fonction qui renvoie une blague de manière asynchrone

onDone est l'action à exécuter quand la promesse résous, dans notre car on déclenche une action qui vient modifier le contexte de notre machine pour mettre à jour l'interface. On pourrait également transitionner vers un autre état si l'on voulait plus de granularité, ce n'est pas le cas ici.

Cela n'a pas été fait mais on aurait également pu gérer un onError pour le cas où la promesse échoue.

Enfin nous avons la clé on qui permet de définir les réponses aux évènements qui correspondent à notre définition.

START_TIMER permet de déclencher le changement de phase vers l'état du timer.

GET_NEW_JOKE permet de changer la blague en re-exécutant les hooks vu plus haut.

Ici très simple, on utilise l'instruction after pour définir une période de temps après laquelle on exécutera une action. Dans notre cas c'est un changement d'état vers choose_loser.

Encore une fois on utilise une référence textuelle vers la configuration de la machine mais on aurait pu simplement passer la durée en clé (ce qui est moins pratique mais plus simple pour tester).

Ici, selon l'environnement React Native que l'on soit en mode développement ou production la durée est raccourcie à 2 secondes au lieu de 10 secondes pour développer plus facilement.

On atterri ensuite dans la phase de choix du perdant, où si quelqu'un à rigolé durant la phase précédente il fait marquer un point à l'équipe adverse.

Ici on utilise encore l'instruction on sauf qu'on y rajoute un paramètre sous forme de tableau.

XState va évaluer dans l'ordre les éléments en y appliquant la condition définie et cond et référencée en option de la machine. Lorsqu'une condition sera bonne XState s'arrêtera et exécutera les actions définies dans le bloc.

Dans notre cas on vérifie si l'évènement à reçu un argument avec la référence vers le perdant, si c'est le cas on adapte le score en cohérence, sinon on migre simplement vers l'étape choose_joke

Maintenant que l'on a réussi à définir notre machine à états, comment utiliser cette dernière avec React ? Et bien c'est très simple grâce à la librairie pour react fournie par XState.

Si vous voulez essayer Jerry, vous pouvez aller télécharger l'application sur IOS ou Android et nous faire un petit retour, cela sera avec plaisir :-)

Comment nous avons utilisé XState pour les premières versions de notre application Jerry, développée en JavaScript avec React Native.

Comment utiliser XState pour gérer l'état d'un jeu mobile React Native?

Les problèmes quand on essaye de gérer un état composite avec des booléens

Essayer de gérer l'état d'une fonction par l'utilisation de booléens pose plusieurs problèmes fondamentaux. Le premier est souvent appelé "explosion booléenne". Pour chaque booléen que nous ajoutons à une fonction, nous augmentons le nombre d'états possibles à un taux de 2^n où n est le nombre de booléens. En faisant le calcul quelques fois seulement, on obtient rapidement une quantité absurde d'états.

Le deuxième problème est que beaucoup de ces états sont des "états impossibles", des états dans lesquels notre application ne devrait jamais se trouver. Par exemple si on gère un état pour un animal avec un booléen estVivant est un autre estEntrainDabboyer on se rend compte qu'on ne peut pas être mort et être entrain d'aboyer en même temps. Pourtant au fur-et-à-mesure que le nombre de booléen s'enchainent et complexifie notre état, il y a de plus en plus de chances qu'à un moment on se retrouve dans un état comme celui-ci, ce qui ne devrait pas arriver.

Pour résoudre ce problème une manière saine est d'énumérer les états possibles et les évènement qui permettre de transitionner d'un état à un autre de manière déclarative, plutôt que de manière impérative.

Ce qui suit m'a pris quelques années à apprendre et surtout comprendre et m'a valu nombre d'essais et d'erreurs dans les logiciels que j'ai conçus. Je vais tenter de vous l'illustrer avec un exemple : Imaginons un logiciel d'achat de Pizzas, on choisit une quantité puis on clique sur « commander 

Une approche naïve avec React serait d'avoir un formulaire de la sorte où l'ont gère la quantité et l'état d'envoi avec deux booléens.

Par la suite on nous demande de gérer des erreurs, puis comme le traitement du formulaire prends un certains temps, on nous demande de gérer un état de soumission du formulaire qui désactive le bouton pendant le chargement.

Nous sommes donc à 3 états booléens, soit 2^3 états possibles, soit 8 états possibles ce qui commence à faire.

Comme vous pouvez le voir, cela devient très verbeux et les possibilités d'erreurs et d'oublies sont assez probables.

Mais, à ce stade, nous devons nous poser une question : est-ce qu'on veut vraiment être le prochain développeur à travailler sur ce formulaire ?

Je ne pense pas. Le code est complexe. Il y a des états à gauche et à droite. Il y a même des paramètres à des endroits où nous ne sommes même pas sûrs d'en avoir besoin. Et nous essayons d'éviter de mettre notre composant dans des états impossibles.

On peut constater que le nombre d'États commence à augmenter très rapidement. Mais avons-nous réellement autant d'états dans notre programme ? Notre formulaire utilise actuellement trois booléens, mais a-t-il vraiment huit états ? Non, la plupart de ces états sont impossibles. Par exemple, nous ne pouvons pas être dans un état où isSuccess, error et isSubmitting deviennent tous vrais. C'est impossible.

Alors pourquoi donnons-nous à nos programmes la possibilité d'être dans des états impossibles ?

C'est quoi l'énumération d'états et comment faire ?

L'énumération, qui consiste à identifier un ensemble de choses une par une, est un moyen simple mais efficace de rendre nos programmes un peu plus robustes.

Compte tenu des mêmes exigences, on rend compte que notre formulaire ne peut se trouver que dans une poignée d'états. Énumérons-les :

Remarquons à quel point il est simple d'envoyer des événements et de s'assurer que notre composant est dans le bon état. Nous avons également beaucoup moins de conditions et de guards qu'auparavant. En éliminant l'existence d'états impossibles, nous avons créé un code dans lequel nous pouvons avoir une grande confiance.

Maintenant reposons-nous la question « souhaite-t-on vraiment être le prochain développeur à travailler sur ce formulaire ? »

En ce qui me concerne la réponse serait oui, mais bien évidemment il existe des outils qui nous permettre d'encore mieux représenter la gestion de nos états. Cela est présenté dans un autre article qui explique comment gérer l'état d'un jeu mobile à 3 étapes par tours en utilisant la librairie X-State

Gérer ses états en utilisant seulement des booléens peut augmenter la complexité du code. Utiliser des énumérations d'états est beaucoup plus productif et maintenable.

Utiliser des énumérations pour gérer des états plutôt que des booléens.

À quoi sert l'attribut « autocomplete » du navigateur ?

L'attribut autocomplete ou autofill permet au navigateur de remplir automatiquement des champs de formulaire si l'utilisateur a sauvegardé des données dans ce dernier.

En 2017 l'auto-complétion à permis aux utilisateurs de gagner un temps énorme, c'est une fonctionnalité dont on a l'habitude de se servir et qui sert beaucoup.

Cependant c'est tellement pratique que parfois le navigateur va remplir des données dans nos formulaires, alors qu'on aimerait qu'il ne le fasse pas pour X raison. Par exemple car il ne le fait pas comme on le souhaite par défaut.

Pour cela la spécification officielle indique qu'il suffit de mettre l'attribut autocomplete à off. Comme présenté ici-même :

Mais comme ça n'est jamais si simple, les navigateurs basés sur chromium n'interprètent souvent pas correctement la valeur de cet attribut.

Et bien que cela soit embêtant, ce n'est pas forcément hors-spécification car en effet :

https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofilling-form-controls%3A-the-autocomplete-attribute

The autocomplete content attribute can be used to hint to the user agent how to, or indeed whether to, provide such a feature

En effet avec le HTML, cet attribut (comme tout autre) est une suggestion au navigateur.

Pour compliquer un peu plus les choses, les navigateurs peuvent également remplir automatiquement les champs de formulaire en se basant sur les attributs name ou id du champ.

C'est ainsi que les navigateurs procédaient avant l'arrivée de l'attribut autocomplete (la bonne vieille époque… ou pas)

Comment utiliser efficacement l'attribut « auto-complete » ?

Pour une prise en charge maximale, il est donc intéressant de bien utiliser les attributs name et autocomplete.

Mais si on souhaite que Chrome (et d'autres navigateurs) arrête de remplir automatiquement les champs, on devrait utiliser un nom, un id et une valeur d'auto-complétion que le navigateur ne reconnaît pas.

Maintenant souvent il suffit de changer uniquement la valeur d'autocomplete, mais dans le doute si vous voulez vraiment vous assurer que cela n'arrivera pas il faut agir sur les trois champs.

Ce que je propose donc pour désactiver la saisie c'est de mettre l'attribut à la valeur nope qui ne corresponds donc à rien (que le navigateur reconnaisse en tout cas). De cette manière le champ n'est plus auto-complété :) On aurait pu mettre n'importe quoi mais je pense que sémantiquement c'est toujours bien d'avoir un nom parlant.

On pourrait penser qu'il suffit de mettre autocomplete="off" mais malheureusement c'est un peu plus compliqué, cet article donne une technique pour solutionner le problème

Empêcher Chrome d'ignorer l'attribut autocomplete=off dans son formulaire HTML

Lorsque l'on développe une application NextJS il est fréquent de vouloir définir des mises en pages communes entre nos différentes pages.

Se pose alors le problème de la réutilisation. La documentation officielle nous propose une approche certes pratique mais un peu sommaire de comment gérer ses mises en page.

Une méthode simple pour gérer ses gabarits

Un composant LayoutFactory qui permet à partir d'une propriété de venir charger dynamiquement un layout donné.

Un fichier de types qui permet de définir un contrat d'interface entre nos page et nos mises en page

Des composants de layout respectant ce contrat d'interface

Et enfin une mise à jour dans le fichier pages/_app.tsx pour prendre en compte notre layout

Commençons par le fichier de définitions de types, ici on a CodingSparkAppProps qui sont nos propriétés qui seront utilisées dans pages/_app.tsx puis on définit CodingSparkPageLayoutProps qui surcharge un type assez générique LayoutArgs avec les layouts qui sont disponibles pour notre application.

On étends bien évidemment les types par défaut de NextJS : NextPage.

Dans le fichier qui suit on notera que par défaut on gère un layout « none » ce qui signifie qu'il n'y a pas de mise en page. C'est utile dans le cas où vous n'avez pas encore migré l'intégralité de vos pages vers ce système de layout.

Ici car on en a peu, on part sur un switch/case mais on pourrait bien utiliser une table de correspondance comme une Map ou un objet. C'est d'ailleurs ce que je vous invite à faire si vous commencez à avoir beaucoup de layouts.

À noter qu'on utilise next/dynamic pour ne charger les layouts que lorsqu'ils sont utilisés afin de d'optimiser les premiers chargements de l'application avec du chunking.

Enfin très simplement on va aller « Taguer » notre page avec les meta-données que l'ont a définies plus haut dans le fichier d'interfaces.

And voilà, rien de bien compliqué on profite même de l'auto-complétion !

La dernière chose qu'il nous reste à faire et brancher nos layouts avec notre application, pour se faire on procède de la sorte dans le fichier page/_app.tsx.

Il ne reste plus qu'à savourer le doux parfum de la réussite… 😌

Un pattern de conception pour gérer facilement ses layouts par page sur une application NextJS.

Gérer différents layouts persistants avec NextJS et Typescript

React Hook Form est l'un des frameworks les plus performants et flexibles pour react et react native pour construire des formulaires. Tandis que yup est l'une des bibliothèques les plus simples et les plus agréables pour valider la structure des données. En combinant les deux, vous obtenez un flux de travail fluide et efficace que je vous suggère fortement d'essayer.

Quelques interrogation me venaient cependant souvent à l'esprit :

Pourquoi devrais-je importer yup dans chaque composant où j'ai un formulaire ? En plus du fait que l'auto-importation de yup est assez bancale avec Typescript.

Comment puis-je écrire moins de code et profiter de l'inférence de type TypeScript ?

Après avoir remarqué que je copiais à chaque fois le même code, j'ai fini par créer ces deux hooks pour pouvoir concevoir rapidement un formulaire avec sa validation dans une application react.

Créer facilement un formulaire avec React Hook Form et Yup pour la validation

Et après quelques réflexions, voici ces extraits de code qui profitent de l'inférence de type TypeScript pour donner l'auto-complétion et la sécurité de type.

Rien de bien compliqué, il suffit simplement de copier le code ci-dessus et essayez de l'utiliser, il a été fait en deux formats différents, chacun ayant son propre but.

Faites attention au fait que vous n'avez pas besoin de passer un resolver aux arguments useform car il sera de toute façon écrasé par l'extrait de code comme vous pouvez le voir.

La vraie valeur ajoutée ici est dans l'inférence de type Typescript qui donne une bonne auto-complétion et la sécurité des types.

En utilisant un schéma yup déjà existant

Ou en utilisant la fonction de construction

Si vous n'avez pas encore de schéma et que vous ne voulez pas importer yup partout, utilisez la fonction d'usinage. De plus, cela permet de jouer avec la validation dynamique.

Cela a un léger coût en termes de performances, car le render est renouvelé à chaque fois, ce qui implique la création d'un nouveau schéma à chaque fois. C'est pourquoi vous pouvez envisager l'autre approche si jamais des problèmes de performances se font sentir.

Cet article propose deux « hooks » pour react-hook-form et yup afin de vite développer vos formulaires sans devoir importer plusieurs fichiers.

Gérer ses formulaires avec react-hook-form et yup avec une validation très simple

Utiliser la fonction process.env pour consommer des variables d'environnement dans son programme NodeJS est très fréquent, c'est d'ailleurs une bonne pratique des «Twelve-Factor App» — un manifeste pour concevoir des applications qui se mettent à l'échelle automatiquement—.

Par défaut quand vous installez les types ambiants TS de NodeJS (@types/node) dans votre projet javascript, les types de process.env sont définis comme tels :

Et bien on voit que l'objet process possède une propriété env de type ProcessEnv (une interface). Cette interface est composée d'un objet ayant des clés sous forme de string et des valeurs string ou non définies.

Super ! Le compilateur typescript ne criera pas si vous tapez process.env.HOST par contre, vous êtes obligés d'aller voir les variables d'environnement injectée pour savoir quelles variables sont disponible à l'utilisation.

Vous en conviendrez : il y a mieux comme expérience de développement.