v11.23

Evolutions sur les formulaires

Fix #193

• useFormNode peut désormais être appelé avec une définition d'entité à la place d'un noeud existant. Vous n'êtes donc plus obligés d'utiliser un store externe global, ou de faire le buildNode vous même dans le composant

• useFormActions :

  • Prend une nouvelle méthode init(init?: () => Promise<EntityToType<E0>>), qui sera appelée à la place de load au premier rendu s'il n'y pas de load à appeler. Elle effectue un set des données retournées par la méthode en paramètre sur le formNode (et non un replace sur le storeNode comme load), puis écrase les données du noeud source par les données du formulaire (avec un replace cette fois-ci).

    Elle permettra de faire des initialisations de données pour la création sans utiliser load (ou un effet externe) quand on a besoin d'un appel serveur et de s'assurer que le valeur de hasChanged du formulaire sera toujours calculée à partir des données initiales. Les données complèteront celles déjà définies dans useFormNode (d'où le set), et init pourra être appelé sans paramètre si on veut juste reset le noeud source.

    Idéalement, tout formulaire utilisé en création devrait appeler init, ce qui ne correspond malheureusement pas forcément à tous les formulaires sans load (il peut être défini dans un useLoad séparé par exemple, et ici on ne voudra pas du tout reset le noeud source).

  • Prend deux nouvelles méthodes create et update, mutuellement exclusives avec save, qui seront appelées par actions.save() selon si on a des params (pour update) ou non (pour create). update sera appelée avec les params puis avec le contenu du formulaire, pour correspondre aux API PUT classiques. Pour le reste, elles sont identiques à save.

  • On ajoute on("init"), .on("create") et on("update"), pour faire comme les autres méthodes

  • On autorise les fonctions de sauvegarde (donc create, update et save) à retourner une primitive, en plus de void ou le type du noeud.

  • Les différents on seront appelés avec la valeur retournée par la fonction correspondante (pour init, load, save, create et update). Cela permettra par exemple de faire on("create", id => router.to(x => x(id))) si votre service de création renvoie un ID.

  • On appelle aussi on("error") pour load, et il sera appelé avec le nom du service en erreur, ainsi que l'erreur elle-même.

  • On expose actions.params, pour pouvoir l'utiliser dans le rendu par exemple (pour distinguer le cas de création)

La documentation a évidemment été mise à jour, et le starter kit utilise également ces nouvelles fonctionnalités, si vous voulez un exemple 🙂

Les petits breaking changes à noter :

• Les stores (source et de formulaire) sont désormais entièrement vidés en cas d'erreur pendant le chargement.
• params() n'accepte plus de surcharge (qui n'était pas documentée d'ailleurs) qui prend plus d'un seul paramètre. Il faut explicitement passer un array dans ce cas.
• Le type de FormActions a évolué pour inclure aussi les types de retours de create, update et save, ce qui peut poser quelques soucis si vous l'avez utilisé en props à certains endroits.

ProblemDetails

Focus accepte désormais nativement des réponses en erreur sous le format ProblemDetails, et utilisera les champs detail ou title en plus de errors pour y récupérer le ou les messages d'erreurs à afficher à l'utilisateur.

On supporte désormais des paires clés/valeurs dans errors (au lieu d'une simple liste plate). Chaque message sera préfixé par sa clé quand il sera ajouté au messageStore, ce qui s'interfacera à priori nativement avec les retours en erreurs de vos APIs de validation côté serveur.

Le seul breaking change la dessus concerne ce qui sera renvoyé à un catch d'un appel d'API :

• avant, on renvoyait la réponse, avec $status et $parsedErrors avec les errors lues du retour serveur.
• maintenant, on renvoie toujours la réponse, avec status s'il n'y était pas (status fait partie de la spec ProblemDetails), et $messages, qui contient la liste des messages ajoutés dans le messageStore.

C'est presque la même chose qu'avant donc 😁