v8.6

list + search = collections

Les deux "modules" list et search ont été regroupés au sein d'un même "module" collections. La distinction était déjà un peu arbitraire, et certaines (nouvelles) fonctionnalités nécessitaient que les composants de listes aient connaissance de ce qu'est un SearchStore.

Concrètement, cela veut dire que tout ce qui était dans focus4/list ou focus4/search est maintenant dans focus4/collections (breaking change). Les imports/exports ont été un peu changés aussi, en particulier les types de recherches sont directement dans focus4/collections au lieu de focus4/search/types (cela impacte le générateur de services Kinetix). Si vous aviez une référence à un composant en particulier, sachez que focus4/list/components est maintenant focus4/collections/components/list, et idem pour la recherche.

En parlant d'imports, computed est maintenant (enfin !) exporté à la racine de focus4 et SearchBar n'est plus exporté de la racine.

Evolutions ListStore/SearchStore

• Un ListStore ne peut plus être muni d'un service de chargement (il ne peut agir que sur une liste locale maintenant). Cette fonctionnalité était inutilisée, surtout que le SearchStore pouvait déjà faire la même chose en permettant de réutiliser (côté serveur principalement) les mêmes services/DTOs.
• L'API ListStore/SearchStore a été un peu homogénéisée, en particulier l'interface commune expose maintenant une propriété list, correspondant à la liste entière dans un ListStore (potentiellement triée/filtrée) et le résultat non groupé d'un SearchStore. Il y a deux implications notables à ce changement :
  • breaking change : ListStore#dataList est maintenant ListStore#list (j'en profite également pour préciser que ListStore#list n'est à priori pas une liste observable (les éléments le sont par contre) puisque c'est une transformation de ListStore#innerList (avec tri + filtrage éventuel), qui elle est bien la liste de base qui est observable. La différence est bien reflétée dans le typage, les deux sont accessibles et le setter de ListStore#list appelle bien celui de ListStore#innerList)
  • StoreList et StoreTable n'ont plus de propriété data et ne prenne toujours que le store en paramètre. Par défaut, ils iront lire la propriété list, sauf si c'est un SearchStore avec des groupes et qu'on précise la nouvelle prop groupCode : dans ce cas, ils afficheront le groupe demandé.
• Toute la logique de chargement/pagination a été déplacée dans les composants de listes, que ça soit pour une liste simple, un ListStore ou un SearchStore. Auparavant, la gestion du "Voir plus"/"Show more" était en double, une fois dans le Results de l'AdvancedSearch pour gérer la pagination serveur et une fois dans le composant de liste pour gérer la pagination locale, qui n'était pas utilisables en même temps. Cela veut dire que :
  • Il est maintenant possible d'écrire un storeListFor ou storeTableFor qui prend directement en SearchStore en paramètre qui gère proprement le "Voir plus"/"Show more", en particulier la pagination serveur.
  • Il est maintenant possible d'utiliser la pagination locale et la pagination serveur en même temps. Par exemple, je défini un perPage de 25 et un SearchStore#top de 50, l'action "Show more" (appellée manuellement ou automatiquement selon isManualFetch) va tour à tour appeler la pagination locale et la pagination serveur, permettant de dissocier le chargement de l'affichage. A ce titre, une prop listPageSize a été ajoutée sur l'AdvancedSearch pour en bénéficier sur le mode non groupé.

isItemSelectionnable

Lié aux stores de liste et de recherche, je mets quand même ce point à part parce que c'est un changement de nature différente.

breaking change isLineSelectionnable sur les composants de liste/recherche à été remplacé par Store#isItemSelectionnable. C'était une erreur de mettre le prédicat sur la liste puisque ça n'affectait pas l'action toggleAll, permettant de sélectionner ainsi des items non sélectionnables.

Nesting d'EntityStore

Il est maintenant possible de spécifier dans makeEntityStore un autre EntityStore dans la liste des noeuds simples. Cela ne change que très peu le fonctionnement des stores puisqu'un store partage la même API (clear(), set()) qu'un StoreNode classique, et c'est même exactement la même chose que si c'était un Node qui n'avait que des sous-Nodes en propriétés.

Cela permet de créer une structure de données un peu plus "en arbre" et de bénéficier d'actions de set() et surtout de clear() qui agissent sur plusieurs stores, liés par la structure. Attention tout de même aux méthodes globales set() des stores : leurs propriétés sont certes nommées mais ne sont pas typées (correspondance impossible entre le Node et le type standard, c'est pareil pour les listes d'ailleurs).