Closed joel-costa closed 5 months ago
Je rajoute une info complémentaire emmenée par flo. On a un passif côté drive : Le skeleton qu'on avait fait avait pris beaucoup de temps de dev et il semble qu'il ralentissait l'arrivée des vraies données.
Unfortunately, the skeleton component is not available in mui v3, we would need to upgrade. I've made this issue : https://github.com/cozy/cozy-ui/issues/1605, to list all the reasons why we'd want to upgrade.
Maintenant que nous sommes en MUIv4, on pourrait rajouter ce composant Skeleton
Pourquoi rajouter et ne pas directement réutiliser ?
Nous n'avons pas de composant Skeleton dans cozy-ui si ? Par "rajouter" je veux dire intégrer le Skeleton de MUI dans cozy-ui.
Pour toi que veut dire "rajouter" et "directement réutiliser" ?
import { Skeleton } from "material-ui"
directly in your application code.
My personal opinion on the subject has changed (yet?): I prefer to have only one entry point to use for UI component. It's easier to document (since when we add it to cozy ui, we have to document it). Also if someday we want to override at some point, it'll be easier.
Ah ok directement dans l'app. J'avais effectivement exclu cette approche d'emblée, pour les raisons citées par @Crash-- je suis resté sur le fait qu'on ajoute d'abord les composants MUI dans cozy-ui, quitte à les importer tel que, pour ensuite utiliser cozy-ui pour importer dans l'app.
A mon avis, cozy-ui ne devrait comporter que:
Les frontières entre Cozy et Material UI seraient ainsi plus claires et il n'y aurait pas ce genre de problèmes ou on doit rajouter un composant dans nos exports pour pouvoir les utiliser.
It's easier to document (since when we add it to cozy ui, we have to document it).
Ca a le désavantage qu'on documente des choses déjà documentées chez Material UI et qu'on ne mutualise pas les efforts avec eux.
Also if someday we want to override at some point, it'll be easier.
Le mécanisme d'override marche déjà pour les librairies externes.
A mon avis les inconvénients de dupliquer les imports/exports sont plus grands que les avantages.
Je laisse l'issue ouverte car nous avons encore en réflexion les skeleton screens et une interrogation entre avoir des composants Skeleton mockant les vrais composants (exemple SkeletonListItem), ou une variant skeleton sur les vrais composants (exemple ListItem variant="skeleton").
Nous avons en revanche ré-exporté le composant Skeleton de Mui dans cozy-ui, et cozy-ui est l'unique source de composants graphiques pour les apps, Mui n'est plus une dépendance de celle-ci.
Je close l'issue, nous avons tranché depuis, pour des composants skeleton spécifique
On avait fait nous même des skeleton screens sur drive et sur le store :
![image](https://user-images.githubusercontent.com/36403934/95834502-567b0100-0d3d-11eb-8d57-ae1c0c777e72.png)
On n'en n'a actuellement pas sur banks, notes, contacts et photos. Est-ce que passer par le composant de MUI pourrait nous permettre de générer facilement des skeleton screens quand on fait de nouvelles pages ? https://material-ui.com/components/skeleton/
Ce n'est pas un sujet urgent du tout mais je suis tombé dessus sur MUI et comme je trouve que ça manque pas mal à nos apps, je l'ajoute ici. Je link au passage un article qui vante les mérites du skeleton screen : https://uxdesign.cc/what-you-should-know-about-skeleton-screens-a820c45a571a