Séparer de façon plus marquée la création de la modification (et consultation)

[JabX]

Pour un formulaire disponible en création/consultation/modification, on utilise beaucoup de id != undefined pour distinguer la création de la modification.

Pour un formulaire en création uniquement, on force la création d'un StoreNode dédié qui ne sert à rien (pas de données serveur à sauvegarder), et on doit recourir à des tricks pour garder le formulaire en édition permanente (edit(() => true)) par exemple.

L'idée serait de rendre la création plus "first class" dans les formulaires, à la fois pour rendre plus claire la distinction quand elle est voulue, et encourager les développeurs à mieux séparer leurs logiques métier entre la création et la modification (avec des routes différentes au moins par exemple).

[JabX]

Aussi, si on utilise le même formulaire en création et en consultation/modification, on peut se retrouver avec un appel à load intempestif après la création (alors qu'on en a pas besoin).

[JabX]

De plus, le nouveau hasChanged n'est pas forcément correct en création puisqu'il compare avec le noeud source (qui n'a pas beaucoup de sens en création), qui ne prend pas en compte les données initiales (qui peuvent d'ailleurs être chargées en asynchrone) du noeud de formulaire. On peut contourner avec un appel genre formNode.sourceNode.replace(formNode) après l'initialisation, mais ce n'est pas le plus propre.

[JabX]

Evolutions prévues :

• useFormNode peut être appelé avec une définition d'entité à la place d'un noeud existant (il appelle buildNode en interne).
• 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 expose actions.isCreation, qui vaut true si on a pas de params, pour pouvoir l'utiliser dans le rendu.

On ne traite pas le sujet du edit(() => true), parce qu'il n'y a pas de solution qui marcherait tout le temps (et que c'est pas si difficile à comprendre et écrire), et on laisse des conditions explicites sur les params dans le useFormNode (on ne pourra pas y utiliser actions.isCreation vu que ça serait une dépendance circulaire...).

On ne pourra pas non plus traiter le sujet du load appelé par un on("create")qui passerait en consultion/modification, parce que qu'il faudrait faire un contournement pas joli pour que ça soit possible, et qu'on est même pas sûr que ça soit toujours souhaitable.