search

opendatateam / udata-front-kit

Verticales thématiques adossées à data.gouv.fr
MIT License
4 stars 3 forks source link

refactor(tech): vue-dsfr et découpage en sous-composants #166

Closed edelagnier closed 8 months ago

edelagnier commented 11 months ago

Related to #144

Exploration Request

Job story

Profil dev : Quand je décompose une page en sous-composant pour améliorer la lisibilité et la réutilisabilité du code, je peux utiliser les composants de la librairie vue-dsfr

Context or situation

Actuellement les composants dsfr ne semblent pas être entiérement transitifs. Lorsque je souhaite partager les propriétés du parents avec les enfants et les mettre à jour via les enfants le transfert d'informations n'a pas le même comportement en utilisant un composant de la library (pas de transfert) et en utilisant des inputs html sur lesquels on applique le css dsfr (transfert fonctionnant tel que documenté dans vue).

Probleme découvert lors du spike pour la découpe (https://github.com/ecolabdata/ecospheres-front/issues/144) et reproduit dans le découpage en sous-composant pour filtrer les bouquets (https://github.com/ecolabdata/ecospheres-front/issues/116)

Problem encountered by users

It doesn't.

Proposal of how to solve the problem

Pour l'instant dans le cadre du POC, j'ai contourné le problème en utilisant les composants purs proposés par https://www.systeme-de-design.gouv.fr/ Sur le moyen terme il serait plus robuste d'utiliser des composants dédiés et mis à jour par les mainteners du dépot vue-dsfr. Il faudrait donc prendre le temps de caractériser plus précisément le problème et le leur faire remonter.

bonjourmauko commented 11 months ago

Merci @edelagnier ! Ne pourrait-on pas résoudre ce problème à l'aide d'un store Pinia par exemple ?

edelagnier commented 11 months ago

Pinia et le principe du store est plus à voir comme les variables globales du projet. C'est effectivement pratique mais ce ne serait pas pertinent d'utiliser des variables globales pour chaque propriétés de sous-objets (risque de conflits et d'effets de bord indésirables et complexification du workflow pour comprendre qui lit et agit sur chaque variable) surtout quand l'implémentation native vue/html est pensée pour permettre des échanges locaux propres et efficaces.

abulte commented 11 months ago

@edelagnier tu as eu un exemple isolé à regarder ? Peut-être un jsfiddle rapide ? Il me semble que vue-dsfr suit les bonnes pratiques actuelles sur ce point (plus de two-way binding systématique) en qu'en utilisant au besoin les événements émis par l'enfant on peut mettre à jour le parent sans problème.

streino commented 8 months ago

Pas assez d'info pour traiter ce ticket