[DOC] ADR-57 - Migration des fichiers SCSS dans le dossier des composants #10481
Conversation
|
Une fois les applications déployées, elles seront accessibles via les liens suivants :
Les variables d'environnement seront accessibles via les liens suivants : |
| - Pour un composant donné, les styles sont plus faciles à retrouver et à maintenir | ||
|
|
||
| ### Inconvénients | ||
| - On est hors du paradigme d’Ember, risque de problèmes futurs inattendus |
There was a problem hiding this comment.
Ça n'a pas encore l'air sec sec mais ils évoquent d'autres approches (<style> blocks for scoped CSS) et questionnement notamment le lien avec le reste de l'écosystème : CSS Modules, Emotion, Styled Components, vanilla-extract...
La RFC est en statut "Ready For Release" alors j'imagine qu'il faut rester attentif sur les prochaines communications.
|
|
||
| ### Inconvénients | ||
| - On est hors du paradigme d’Ember, risque de problèmes futurs inattendus | ||
| - Est-ce qu'on garde les styles globaux dans le dossier "styles" ? |
There was a problem hiding this comment.
Ça me parait être le moins risqué avant qu'ils n'aient tranché sur la direction. Ma crainte notamment c'est que les fichiers SCSS soient embarqués dans le build et donc alourdirait le build final. C'est ce qu'on avait remarqué en essayant de regrouper les fichiers de tests au plus proche des composants. J'avais vérifié pour les styles en l'état : aucun impact.
There was a problem hiding this comment.
Même réflexion, je serais assez partante pour ça aussi (je l'ajoute à la solution dans l'ADR)
There was a problem hiding this comment.
question :
Pour les tests c'est HS. mais ça doit se configurer au build d'exclure certains type de fichiers ?
There was a problem hiding this comment.
Pour les tests c'est HS. mais ça doit se configurer au build d'exclure certains type de fichiers ?
On n'avait pas creusé ce point pour ne pas trop s'écarter des reco d'Ember
|
|
||
| Dans le cas des styles, c'est parfois laborieux de retrouver le fichier correspondant au composant sur lequel on travaille. | ||
|
|
||
| Le paradigme des frameworks plus récents comme VueJS ou Svelte propose un fichier unique qui intègre la logique, le template, et son css scopé. Dans le cas de ReactJS, la norme est de mettre le fichier CSS à côté du fichier de composant correspondant. |
There was a problem hiding this comment.
nitpick : "frameworks plus récents" que quoi ? 🫣
There was a problem hiding this comment.
Je ne vois pas en quoi c'est utile dans l'argumentation de préciser ce point. Ils "ont des paradigmes différents" est suffisant, non ?
Est-ce que quelque chose de nouveau est forcément mieux ? 😄
There was a problem hiding this comment.
Hmm, on peut remplacer "récent" par "les plus utilisés depuis plusieurs années" ?
There was a problem hiding this comment.
suggestion
la colocalisation des fichiers ou l'intégration dans un même fichier dans la majorité des frameworks permet une DX (developer experience) plus agréable ?
There was a problem hiding this comment.
@xav-car c'est tellement bien formulé 👌
mcampourcy
force-pushed
the
adr-057-css-files-close-to-component-files
branch
from
6308cf6
to
056180a
Compare
🍂 Problème
Le paradigme d’Ember impose de séparer tous les fichiers (controllers, templates, styles) en gardant la même arborescence pour s’y retrouver. Dans le cas des styles, ça peut être franchement laborieux de s'y retrouver.
🌰 Proposition
Création d'une ADR proposant de mettre les fichiers de style dans le dossier des composants.
🎃 Remarques
RAS
🪵 Pour tester