Implementer availableColumns dans le columns Picker.

[Samuel Baptista]

Sur ichtus, on a un mécanisme spécifique aux bookings et je trouve dommage qu'il n'ai pas été porté sur natural directement. Je propose de le faire.

Je soupçonne que pour des raisons de temps, ca n'a été fait que dans ichtus car la méthode simple de faire ca nécessite d'écrire dans les template, et ca aurait été un changement à faire manuellement sur tous les projets.

Je veux parler de availableColumns qui sert à limiter le nombre de colonnes visibles dans le date Picker. Actuellement on a un système bien qui permet de savoir quelles colonnes cocher, mais il se peut qu'il y ai des colonnes secrètes à cacher, par exemple quand on utilise la même vue entre back et front office, ou simplement entre deux vues qui n'ont pas la pertinente pour afficher toutes les colonnes.

availableColumns peut être configuré aussi bien dans le routing (via data) que dans le template (via un @input).

Et je pense qu'il faut porter cet usage dans natural.

Il faudrait idéalement nous affrandir de la lourdeur de devoir expliciter dans le template un *ngIf <span *ngIf="columnIsAvailable('bookable')" naturalColumnsPickerColumn="bookable">Item</span>pour chaque colonne. Et je pense qu'à l'inititialisation du ColumnsPicker on a déjà tout ce qu'il faut pour faire ca sans taguer le template.

[Adrien Crivelli]

Pourrais-tu montrer un exemple d'utilisation de ce que tu imagines ?

Je pense que ce travail doit être mis en relation avec https://support.ecodev.ch/issues/8670#note-3, que je pensais faire relativement bientôt si pas plus de retours de ce côté là.

Après cet autre changement, alors les colonnes du picker ne seraient plus définies par template, mais par une liste d'objets. Cela devrait offrir un peu plus de souplesse pour manipuler cette liste. Soit au sein de Natural, soit à l'extérieur.

<natural-search
      [availableColumns]="[
         {
             id: 'name',
             name: 'Nom',
         },
         {
             id: 'code',
             name: 'Code',
         },
         {
             id: 'supplierPrice',
             name: 'Prix du fournisseur',
             show: routeData?.isAdmin   // Ici équivalent fonctionnel du ngIf
         },
      ]"
></natural-search>

On pourrait alors imaginer un nouveau NaturalAbstractList.availableColumns qui serait un cousin de l'existant NaturalAbstractList.selectedColumns dans le sens ou il pourrait aussi être alimenté via @Input ou par routing data, ou par simple override dans la class enfant (ce qui serait sûrement le cas le plus courant).

PS: Ah, mais j'oubliais, où d'autre entrevois-tu le besoin pour cela ?

[Samuel Baptista]

Là le besoin c'est pour les services (via profil) dans ichtus. On a une vue unique bookables.component.html et dans le petit menu du columns picker y a plein de colonnes d'admin visibles dans le front office. On peut tjs les cacher avec des *ngIf mais le plus propre serait de configurer ça dans le ProfileRouting comme on le fait déjà pour les bookings (via l'attribut data.availableColumns).

Après moi j'ai de la dispo et pas grand chose dans le pipeline, donc je pourrait m'occuper de ça. En fait c'était ce point que je devais encore faire pour ichtus, mais là c'est sûr que ca nécessite des devs d'une plus grande ampleur avec le ticket que tu mentionne.

[Sylvain Tissot]

availableColumns a été introduit sur Ichtus pour pouvoir masquer des colonnes en fonction de la page afin de pouvoir réutiliser le même composant sur des listings front et back-office, ce dernier affichant typiquement des colonnes supplémentaires. Avec le recul, ce genre de cas d'utilisation pouvant être utile à d'autres apps, je trouverais bien de migrer ce input dans NaturalAbstractList.
Par exemple Epicerio utilise le même composant de listing des produits en front et back avec un test sur un paramètre de route pour décider quelle colonne montrer:

<span *ngIf="routeData?.isAdmin" naturalColumnsPickerColumn="supplierPrice">Prix du fournisseur</span>

Cela suffit pour 2 modes d'affichage, mais si on commence à réutiliser le composant ou template sur 3 vues ou davantage avec chacune des colonnes activables et visibles par défaut différentes, cela manque de souplesse.

Si on l'introduit dans NaturalAbstractList, il ne serait pas nécessaire d'adapter tous les templates et composants qui l'utilisent: le availableColumns comme défini dans Ichtus est nul par défaut et signifie que toutes les colonnes sont disponibles dans le sélecteur. De plus, dans le template, un *ngIf="columnIsAvailable('columnName')" n'est nécessaire que sur les colonnes à visibilité conditionnelle: celles qui sont affichables dans tous les cas n'ont pas besoin de ngIf.

Je ne suis pas trop favorable de mélanger les availableColumns dans NaturalSearch, car cela le rend trop dépendant de NaturalAbstractList alors qu'il peut être utilisé séparément (cf. observatoire de OKpilot)

[Samuel Baptista]

Je pense qu'Adrien a écrit natural-search mais il pensait sûrement au columns-picker.

Ce dev en combinaison avec le ticket linké par Adrien nous permettrait de n'avoir même pas à écrire de *ngIf dans le template (jamais) puisque tout serait décrit en amont par de la config.

[Adrien Crivelli]

Je ne suis pas trop favorable de mélanger les availableColumns dans NaturalSearch, car cela le rend trop dépendant de NaturalAbstractList alors qu'il peut être utilisé séparément (cf. observatoire de OKpilot)

Dans ObservatoryComponent, je ne trouve aucune utilisation de NaturalColumnsPickerComponent, mais seulement de NaturalSearchComponent. Il va de soit que même après le refactor que je propose, il restera possible de continuer d'utiliser NaturalSearchComponent sans aucune notion de colonne, comme c'est le cas dans l'observatoire. Donc je ne pense pas que cela soit un cas valide à l'encontre du refactor.

Et le fait que NaturalAbstractList permette de forwarder certaines configurations depuis ses inputs ou son routing vers le nouveau NaturalSearchComponent ne me semble pas être une contrainte d'inflexibilité. C'est juste une possibilité de facilitation. Mais NaturalSearchComponent reste tout à fait utilisable de façon totalement indépendante.

Je pense qu'Adrien a écrit natural-search mais il pensait sûrement au columns-picker.

Non, je pensais bien à NaturalSearch. L'idée est bien d'avoir plus que NaturalSearch et que les applications n'utilisent plus jamais directement NaturalColumnsPickerComponent. Techniquement parlant il est possible que NaturalColumnsPickerComponent disparaisse totalement du code, ou non, mais cela deviendrait un détail d'implémentation de Natural dont les app n'ont plus à se soucier.

[Adrien Crivelli]

Fait dans e3a2189, mais un peu différemment que mes derniers commentaires.