The Plan about cozy-ui HOT 34 CLOSED

@ptbrowne

Je ne vois pas trop l'intérêt d'avoir ces composants si simples. Pour moi, des composants react-toolbox + le thème cozy-ui + classes utilitaires régleront le point 1 (je rejoins @y-lohse).

On ne pourra pas utiliser que des composants react-toolbox, on a d'autres besoins de choses toutes simples, ce qui veut dire que des classes vont continuer à polluer le code applicatif. Pas fan. On est bien d'accord que c'est pas une priorité absolue, mais un confort supplémentaire qui peut s'implémenter au fur et à mesure.

A part les classes utilitaires de spacing, text, couleurs et boutons, je ne vois pas trop pourquoi il est nécessaire de penser maintenant à offrir à la communauté un moyen d'utiliser un autre framework.

Vu qu'on veut de toute façon exposer le thème cozy sous forme de variables, ça laisse le champ ouvert à ceux de la communauté qui voudrait utiliser un autre framework, pas besoin d'aller plus loin pour l'instant. C'était le sens de ma proposition, mais peut-être n'était-ce pas assez clair. Après, je rejoins @y-lohse, si on fait des classes pour nos composants, on peut très facilement proposer une feuille de style à coller dans son app.

@GoOz

Oui non je comprends, mais on devrait pouvoir dire fuck it a tout leur CSS et y foutre tout le notre parce que là… c'est pas tentant du coup

C'est juste pas possible en fait, parce que le CSS d'un composant d'UI avancé comme propose react-toolbox comprend le style visuel ET des styles liés au comportement du composant, par exemple le positionnement absolu d'un élément précis, ou du z-index ;), ou...

J'ai juste un problème avec l'idée de coder notre lib dans le but de rentrer dans le fonctionnement d'une autre lib. J'y vois trop de dépendance, voire de la surcouche. Et là aux premiers abords, je suis juste pas confiant mais je vais attendre le POC pour fixer mon avis :)

On code pas tellement notre lib, on fait juste une fine surcouche qui injecte le thème cozy dans la lib et réexporte les composants. Comme tu dis, attendons le POC, mais je suis plutôt confiant.

from cozy-ui.

Je pense que ce qui reflète le mieux The Plan c'est ce commentaire.

from cozy-ui.

J'ajoute à mon précédent commentaire que les bibliothèques (les deux derniers points) ne se font pas en amont, mais en aval.

Lorsque le besoin apparaît :

1. une implémentation naïve à partir des specs css apparaît dans le projet ;
2. une fois rassuré sur le besoin et sa pérennité, on extrait pour mettre dans une lib ;
3. on partage le composant de la lib en l'adaptant aux autres projets.

from cozy-ui.

@enguerran :

Au pire, on peut citer et répondre en-dessous

Ah ben oui tiens :p

from cozy-ui.

@enguerran c'est exactement ça. Je n'étais pas forcément convaincu de la nécessité de l'implémentation CSS des classes de base, mais au vu de la remarque de @y-lohse je ne suis pas loin de changer d'avis ;)

@goldoraf si besoin, j'ai mis tout ça dans un gist pour archive : https://gist.github.com/enguerran/f9c9b2f1b7d1018e67a312676fb9bd7b

from cozy-ui.

J'y vois trop de dépendance, voire de la surcouche.

Je vois ça comme ça : on a pas les ressources pour faire un framework CSS. On a seulement les ressources pour faire un thème CSS, on est donc obligé de choisir une dépendance. Avec le POC, on aura plus de visibilité sur si notre relation avec cette dépendance peut être fructueuse 🙂

from cozy-ui.

@ptbrowne on fera l'explo plutôt dans cozy-santé ;)

Je suis d'accord avec les différentes propositions de @goldoraf et l'implémentation de @enguerran.

Je voulais juste ajouter ceci:
Nous parlons de design, d'UX et le gros point noir que je vois jusqu'à maintenant, c'est que nous avons eu peu d'interaction avec Luc dans notre démarche autour de cozy-ui. Nous avons peu challenger les designs que l'on nous proposait pour avoir justement le moins de différence entre tous nos designs (même si actuellement ils sont très ressemblant, ça va se complexifier dans le temps). J'aimerai vraiment que Claire soit au centre mais il faudrait aussi une personne qui soit plus technique pour piloter et avoir une vue d'ensemble des designs. Forcément je vois en @GoOz la personne idéal (si ça t’intéresse évidemment et s'il y a un vrai besoin)... mais ça sort sûrement de cette discussion.

from cozy-ui.

Au niveau UI, comme cozy-ui n'est pas mature, sur 2 applis différentes, cozy-santé et cozy-bank, on a deux sélecteurs de comptes custom qui sont différents. On gagnera de la cohérence sur ces deux points pour moi.

Désolé mais ça, ça n'a rien à voir avec Cozy-UI cette histoire. S'il y a deux sélecteurs de compte différents sur les deux apps alors il y a eu un mic-mac au niveau conception, pas côté lib CSS.

Si il y a quelque chose en moins à se soucier, personnellement je suis pour :)

Et je pense que c'est une erreur de ne pas s'en soucier. La surcouche pratique d'aujourd'hui sera la dette technique rigide de demain. C'est ce qui me fait le plus peur avec cette histoire de React-Toolbox. Je suis pas franchement sûr que la souplesse de cette lib soit au rendez-vous.
Et si demain on doit dire non à toutes les modifications design demandées par le produit sous prétexte que la lib ne le permet pas… à mon avis, on aura atteint un niveau d'absurdité inqualifiable.
La seule raison viable de refuser une modifications design serait que les browsers ne le permettent pas, parce que c'est le seul niveau où on est pieds et poings liés et on doit faire avec.
Dans le cas de la lib, on la choisit et si on choisit délibérément une lib qui nous mets des bâtons dans les roues, je sais pas où on va atterrir mais ce sera pas beau.

Mais j'attends de voir le POC… dans le doute.

from cozy-ui.

Première ébauche de réponse (après 5min de considération 😛)

Besoins

1. Celui là je suis pas sûr de comprendre où tu veux en venir. Je conçois que la syntaxe className={classNames(styles['pho-truc-bidule'], styles['pho-machin-chose']} soit verbeuse, polluante visuellement et disons-le chiante à écrire à chaque fois, on est même carrément d'accord. Mais il faudra bien à un moment ou un autre mettre des classes CSS quelque part du coup, non ? Ou alors tu penses justement à un truc à la ReBass où tout est un composant et c'est à l'intérieur de ce composant qu'on met des classes en fonction des paramètres qu'on lui a donnés ?

2. Concernant le layout, il me semble que le problème est fixé. c'est juste qu'on ne peut pas le déployer partout encore notamment sur Drive. Il n'y a certes pas encore de composant layout qui serait certes bienvenue mais ça c'est un détail.

3. Complètement OK

4. Complètement OK aussi, jamais perdu de vue cet objectif, même si on est encore loin de l'atteindre à l'heure actuelle.

Propositions

1. Oui, c'est faisable, c'est plus que souhaitable mais c'est du taf et le comble que c'est pas le genre de truc qu'on peut faire après-coup, c'est à prendre en considération de suite.
2. Finalement, sans forcément utiliser ReBass on ferait un truc à la ReBass ?
3. Ce serait une lib donc de modules fonctionnelles React. Pourquoi pas.

Tout ceci étant dit, une chose m'inquiète un peu. Cette vision idéale enchanteresse me plait beaucoup, mais ça demande une réflexion sur l'architecture, une vue d'ensemble des composants existants, beaucoup de temps d'écriture et d'arbitrage, etc et je vois mal comment arriver à ce résultat sans du temps dédié propre. Jusque là je me démerde pour faire évoluer Cozy-UI tant bien que mal quand une carte me le permet ou quand j'ai du temps un vendredi de fin de sprint mais c'est très disparate. Je dis pas qu'il faut tout faire d'une traite, il y a évidemment différente étape de stabilité possible mais ça se fera pas en 1h par-ci par-là entre deux cartes ou deux café. Je pense qu'il nous faudrait une stratégie, que dis-je, une milestone 😆

My 50 cents

from cozy-ui.

D'accord dans l'ensemble, en particulier les propositions 1 et 3. Pour la 2 en revanche — collection de composants visuels — je ne suis pas tout à fait d'accord.

Des composants visuels pour des éléments très atomiques, comme des boutons ou des titres, ca serait effectivement bien. Aujourd'hui il faut à chaque fois leur créer une classe dans stylus ET ca pollue notre code applicatif.

En revanche, on ne pourra pas avoir de composants visuels pour tout — il y a toujours des cas uniques pour lesquels ça a peu de sens de faire un composant, et des cas ou on voudra une aggrégation de composants (une icone en position absolue dans un coin, par exemple).

A la place, je pense qu'il vaux mieux créer (ou utiliser, ou étendre) une lib de classes css. La ou je te rejoins, c'est que ces classes doivent être atomiques / fonctionnelles. C'est typiquement ce que propose basscss ou tachyons. C'est la même philosophie que Rebass, mais:

1. Les cas spéciaux sont moins lourd à gérer
2. C'est ultra simple de "composer" ces classes quand on veux plusieurs comportements
3. C'est agnostique en terme de techno (c'est juste du css)

Le point 3 en particulier est important parce que je pense que tu te trompes quand tu dis

afin que ces développeurs [de la communauté, ndlr] puissent aisément thémer la lib de leur choix.

En tant qu'ex dev cozy sur mon temps libre, je n'aurais jamais pris la peine de thémer la lib de mon choix, même si les variables pour le faire étaient exportés. Soit tu me donnes un fichier css que je peux utiliser, soit je fais un truc à ma sauce.
Si on veux que les applis tierces aient un look & feel cozy, il faut que les efforts et les compétences pour y arriver soient moindre. Et donc proposer une lib de classes css permettrait ca (et pas une lib de variables css ou de placeholder stylus ou autre combine).

Ensuite, des composants visuels peuvent être créés, en s'appuyant sur ces classes fonctionnelles. Et là aussi ca peut être fait progressivement selon la règle boy scout.

Je vous propose aussi ca comme lecture : Functional CSS - The Good, The Bad, and Some Protips for React.js Users

from cozy-ui.

En tant qu'ex dev cozy sur mon temps libre, je n'aurais jamais pris la peine de thémer la lib de mon choix, même si les variables pour le faire étaient exportés. Soit tu me donnes un fichier css que je peux utiliser, soit je fais un truc à ma sauce.
Si on veux que les applis tierces aient un look & feel cozy, il faut que les efforts et les compétences pour y arriver soient moindre. Et donc proposer une lib de classes css permettrait ca (et pas une lib de variables css ou de placeholder stylus ou autre combine).

Alors oui et non. Certains aime pouvoir personnaliser un peu mais n'ont pas le skill pour faire leur propre sauce. Je suis plutôt un homme du juste milieu, quelques options serait bien d'avoir, par contre pas trop. Les couleurs, polices oui ! les box-shadow, bordures je suis beaucoup plus mitigé.
Je suis pas sûr que ce soit un bonne idée de trop complexifier le truc au cas où. Et puis merde, le truc sympa avec le CSS c'est que l'overwrite de l'existant est simple de base, une micro surcouche fera pas de mal au perfs.

tl;dr: du themable un peu oui mais pas trop.

from cozy-ui.

@GoOz

Bon, dommage qu'on puisse pas répondre dans le texte comme avec un mail, mais je vais essayer de traiter tes différents points quand même ;)

Besoins

1. Effectivement, il faut bien mettre des classes CSS quelque part, et l'idée est bien de les isoler dans des composants séparés à la Rebass.
2. Tant mieux si les pbs de layout sont réglés, j'imagine que c'est les virtual lists qui empêche pour l'instant de le déployer sur Drive. @ptbrowne et @kosssi étaient néanmoins très insistants sur la nécessité d'avoir des composants dédiés vu le nombre d'apps que l'on va être amené à créer/maintenir.

Propositions

1. Tout à fait, c'est du taff et on a tout intérêt à le démarrer au plus vite. Le plus difficile sera de se synchroniser.
2. Exactement.

Comme tu le dis, tout ça c'est du boulot et ce sera compliqué à faire en parallèle de nos tâches courantes, mais ma proposition contient cependant des premiers pas relativement faciles à franchir. Le reste dépendra de notre courage et d'un chouïa d'organisation !

from cozy-ui.

Ce qui nous ferait une organisation comme ceci, si j'ai bien compris :

variables et conventions

NB : l'implémentation reste un détail mais on peut imaginer avoir un json, un fichier css avec des variables, un fichier sass avec des variables, etc.

:root {
  --color-red: #f52d2d;
  --color-purple: #a75bcb;
  --color-blue: #2d8af2;

  --main-font-size: 1em;
  --main-line-height: 1.5;
  --main-padding: 1em 0.5em;

  --border-radius: 2px;

// etc.
}

implémentation css des classes de base

avec des classes

.btn {
  border-radius: var(--border-radius);
}

.list {
  font-size: var(--main-font-size);
}

un styleguide autogénéré servant de doc

Dans le genre de ce que fait mailchimp : https://ux.mailchimp.com/patterns/forms

une bibliothèque de composants visuels

NB : la mise à disposition des classes ou des styles est un détail d'implémentation (css-in-js, style-loader, etc.)

import style from 'style.css'

const SimpleButton = (props) => (
 <button class="button">{props.children}</button>
)

const CancelButton = (props) => (
 <button class="button button-cancel">{props.children}</button>
)

export default const Button = (props) => {
  switch(props.type) {
    case 'cancel':
      return <CancelButton {...props} />;
    default:
      return <SimpleButton {...props} />;
   }
}

Button.propTypes = {
  type: propTypes.string
}

Enfin une bibliothèque de composants fonctionnels

class MediaButtons extends React.PureComponent {
  state = {
    pressedId: undefined
  }
  clickButton = () => id => this.setState(state => { ...state, pressedId: id })
  isPressed = id => this.state.pressedId === id

  render () {
    <div>
      {this.props.functions.map(function => 
        <Button
          class={classname({ pressed: this.isPressed(function.id)
          onClick={this.clickButton(function.id)}
        >
          {function.name}
        </Button>
    </div>
  }
}

from cozy-ui.

@enguerran c'est exactement ça. Je n'étais pas forcément convaincu de la nécessité de l'implémentation CSS des classes de base, mais au vu de la remarque de @y-lohse je ne suis pas loin de changer d'avis ;)

from cozy-ui.

@GoOz les box-shadow et borders font partie du thème cozy, ne pas les exposer rendrait la création d'un thème react-toolbox par ex. beaucoup plus compliquée.

from cozy-ui.

message de @goldoraf :

Bon, dommage qu'on puisse pas répondre dans le texte comme avec un mail, mais je vais essayer de traiter tes différents points quand même ;)

Au pire, on peut citer et répondre en-dessous

from cozy-ui.

Tout à fait raccord avec le résumé d'enguerran. Au moins sur le papier, je pense que c'est exactement vers ca qu'il faut se diriger. Si tout le monde est ok la dessus, on pourra réfléchir aux technos, aux libs qu'on utilise ou pas, etc.

(@GoOz : je pense que ce n'est pas moi que tu voulais citer dans ce message, si ?)

from cozy-ui.

@goldoraf

les box-shadow et borders font partie du thème cozy, ne pas les exposer rendrait la création d'un thème react-toolbox par ex. beaucoup plus compliquée.

Ah ? React-Toolbox veut tout pouvoir gérer ? faut que j'approfondisse le sujet.

@y-lohse Si 😶 j'ai ptête pas compris ce que tu voulais dire alors.

from cozy-ui.

@GoOz

Ah ? React-Toolbox veut tout pouvoir gérer ? faut que j'approfondisse le sujet.

Je ne sais pas ce que tu veux dire par "pouvoir tout gérer", ce que je voulais dire c'est que si tu veux skinner la modal de react-toolbox par exemple, il faut exposer les box-shadows spécifiques à cozy. C'est plus clair ?

from cozy-ui.

@goldoraf Ah oui parce que React-Toolbox c'est pas une lib de logique juste ? Elle est livrée avec son propre style ?

from cozy-ui.

@GoOz oui, elle a son propre style orienté Material Design. Et pour avoir essayé de proposer Bosonic sans thème de base, je peux t'assurer que c'est à ne pas faire, les gens fuient parce que c'est moche :p

from cozy-ui.

Oui non je comprends, mais on devrait pouvoir dire fuck it a tout leur CSS et y foutre tout le notre parce que là… c'est pas tentant du coup

from cozy-ui.

1. OK avec le point 1 = avoir un JSON qui contient les variables. On pourrait créer un fichier CSS de thème plein de classes utilitaires (textes, couleurs, padding, margin) à partir de lui et un thème pour react-toolbox

2. Je ne vois pas trop l'intérêt d'avoir ces composants si simples. Pour moi, des composants react-toolbox + le thème cozy-ui + classes utilitaires régleront le point 1 (je rejoins @y-lohse).

3. OK pour react-toolbox avec un thème à la Cozy.

4. A part les classes utilitaires de spacing, text, couleurs et boutons, je ne vois pas trop pourquoi il est nécessaire de penser maintenant à offrir à la communauté un moyen d'utiliser un autre framework. J'ai l'impression qu'on a essayé de faire ça et que ca conduit à des choix suboptimaux. Avec le problème de license de React qui a disparu, je ne vois pas trop de soucis à dire à la communauté "On a fait des choix pour vous". Personnellement je trouve ca plus clair même en tant que contributeur.

Oui non je comprends, mais on devrait pouvoir dire fuck it a tout leur CSS et y foutre tout le notre parce que là… c'est pas tentant du coup

Pourquoi tant de haine :D ? Si tu enlèves le CSS de ce framework, la moitié des composants ne vont pas marcher. Je vois pas trop pourquoi on cherche à réinventer la roue. Tu dis toi même que tu n'as pas de temps à consacrer à ça. Pour moi si on met nos padding, nos margin, nos box-shadow (à standardiser déja), nos font-size (à standardiser), react-toolbox ressemblera à cozy. C'est d'ailleurs ce que l'on va tester sur cozy-sante.

from cozy-ui.

J'ai juste un problème avec l'idée de coder notre lib dans le but de rentrer dans le fonctionnement d'une autre lib. J'y vois trop de dépendance, voire de la surcouche. Et là aux premiers abords, je suis juste pas confiant mais je vais attendre le POC pour fixer mon avis :)

from cozy-ui.

et réexporte les composants

Je ne te suis pas là. Pour moi pas besoin de réexporter les composants non ?

IMHO, je veux juste pouvoir faire :

import 'react-toolbox.css'
import 'react-toolbox-cozy.css'

import Button from 'react-toolbox/lib/Button'

<Button>Hello World !</Button>

from cozy-ui.

@ptbrowne

Je ne te suis pas là. Pour moi pas besoin de réexporter les composants non ?

My bad. Je m'étais arrêté à la portion de la doc décrivant cette façon de faire :

import Button from 'react-toolbox/lib/button/Button';
import buttonTheme from './theme/button.scss';

const ThemedButton = (props) => (
  <Button theme={buttonTheme}  {...props} />
);

export default ThemedButton;

Mais, comme ils le disent eux même :

With this technique you have to create wrappers for every component and this is not cool at all... but don't worry, we can provide the theme via context to avoid this.

Donc la bonne solution serait d'utiliser leur ThemeProvider :

import React from 'react';
import { render } from 'react-dom';
import { ThemeProvider } from 'react-css-themr';
import theme from './theme/theme.js';
import App from './App.js';

render(
  <ThemeProvider theme={theme}>
    <App />
  </ThemeProvider>
, document.getElementById('app'))

Comme ça, chaque composant utilisé sera thémé automatiquement \o/

from cozy-ui.

OK je vois. Effectivement ca me paraît mieux que d'exporter chaque composant :D Par contre je ne saisis pas trop pourquoi on utilise un <ThemeProvider> plutôt qu'un <link href='theme.css' /> ?

from cozy-ui.

Tout comme @GoOz je reste sceptique à l'idée que cette solution de react-toolbox va solutionner tous nos problèmes avec cozy-ui. Pour moi on commence à avoir quelque chose un peu mature qui fonctionne côté cozy-ui il lui manque juste une vision et une direction claire pour moi (sans mauvais jeu de mots), ce qui est en cours avec la v4 normalement (on vire les classes stylus à étendre, on vire css modules dans les composants, on expose plus de class CSS...). Je demande qu'à être convaincu et à voir le POC de @kosssi pour faire mon avis et voir plus concrètement.
Pour moi ce serai juste résoudre des problèmes et en avoir d'autres puisqu'il faudrait cette fois-ci travailler sur une surcouche à react-toolbox et la maintenir. Et qu'en est-il des composants un peu plus complexes comme l'Alerter qui passer par redux ou encore le HOC polyglot?
Concernant le theme CSS pour moi c'est quand même le minimum si on passe à react-toolbox, c'est à mon sens important d'avoir une identité visuelle cohérente au sein de nos interfaces et le material-design est pour moi une solution de facilité et pas originale (après les goûts et les couleurs comme on dit).
J'ai l'impression de jouer le mauvais rôle en freinant les ardeurs mais je préfère être prudent et bien voir vers quoi on se dirige pour éviter un éventuel "Finalement ça nous a apporté plus de problèmes sur quelque chose qui fonctionnait" ou encore "Ah ouai on avait pas vu cet aspect là".

from cozy-ui.

Pour moi on commence à avoir quelque chose un peu mature qui fonctionne côté cozy-ui

A mon avis, cozy-ui est loin d'être mature. Par exemple, il manque encore plein de composants et la doc vient juste de commencer. On est vraiment très loin de framework comme react-toolbox et ca demande énormément de travail de se mettre à niveau.

c'est à mon sens important d'avoir une identité visuelle cohérente

Material design est très cohérent au niveau UX. C'est déjà beaucoup. Au niveau UI, comme cozy-ui n'est pas mature, sur 2 applis différentes, cozy-santé et cozy-bank, on a deux selecteurs de comptes custom qui sont différents. On gagnera de la cohérence sur ces deux points pour moi.

Sur l'identité visuelle, on est d'accord qu'il faudra un thème.

solution de facilité et pas original

IMHO, ce n'est pas notre boulot d'être originaux(les). Pour moi, à notre niveau, ca n'est pas parce que le design est original que l'on va gagner des utilisateurs. Les utilisateurs ont besoin comme tu l'as dit de cohérence et d'expériences utilisateurs nickel. On peut itérer plus facilement sur l'UX quand on a un langage de composants déjà prêt que l'on n'a pas besoin de recoder.

Et qu'en est-il des composants un peu plus complexes comme l'Alerter qui passer par redux ou encore le HOC polyglot?

Si l'alerter est très fortement lié à redux, c'est qu'il a un problème.

Concernant le HOC polyglot, ca passe par le context react, il n'y aura pas de soucis à l'utiliser avec n'importe quelle librairie.

from cozy-ui.

Un proverbe qui me vient en tête concernant cela c'est "Choose your own battles". On fait quelque chose de difficile, avec des problématiques de connecteurs, de gestion de plein d'applications différentes, de scaling des serveurs, de sécurité, de changement de mentalité des gens. Si il y a quelque chose en moins à se soucier, personnellement je suis pour :)

from cozy-ui.

@Claiw 🎉 Je pense que ton avis là dessus peut avoir de la valeur.

from cozy-ui.

@CPatchane je suis un peu surpris par ta réponse, et j'ai le sentiment que tu "simplifies" un peu la proposition qui a été faite, ou alors que tu en omets des raisons. Par exemple :

je reste sceptique à l'idée que cette solution de react-toolbox va solutionner tous nos problèmes avec cozy-ui.

Je n'ai jamais dit que react-toolbox allait solutionner tous nos problèmes. Il en solutionne un : il nous offre des composants d'UI avancés type DatePicker (dont nous avons besoin, sur bank pour commencer) que l'on serait bien idiots de s'amuser à recoder. C'est tout, et c'est déjà pas mal. react-toolbox viendrait donc en complément de l'existant, pas le remplacer. L'Alerter, puisque tu en parles, pourrait évoluer en exploitant des composants de react-toolbox tout en conservant sa logique basée sur redux.

Concernant le theme CSS pour moi c'est quand même le minimum si on passe à react-toolbox

C'est évident, et cela a d'ailleurs été précisé plus haut.

J'ai l'impression de jouer le mauvais rôle en freinant les ardeurs mais je préfère être prudent

La prudence est de rigueur bien sûr, d'où l'idée de commencer par un PoC avant de décider quoi que ce soit.

Pour moi on commence à avoir quelque chose un peu mature qui fonctionne côté cozy-ui il lui manque juste une vision et une direction claire pour moi

Ben justement, c'était un peu l'idée de cette issue :p

@GoOz

La surcouche pratique d'aujourd'hui sera la dette technique rigide de demain.

Tu imagines la dette technique que représenterait le fait de développer notre propre DatePicker ? C'est à nous de faire en sorte que cette surcouche soit intelligemment conçue afin d'être la plus fine possible et qu'elle s'appuie sur notre existant CSS.

from cozy-ui.

@CPatchane a écrit :

ce qui est en cours avec la v4 normalement (on vire les classes stylus à étendre, on vire css modules dans les composants, on expose plus de class CSS...)

Je ne suis pas sûr que tout le monde soit sur la même longueur d'onde. J'ai tenté d'avoir une discussion avec @GoOz sur css-modules et ça n'a pas été très facile :

1. «on vire les classes stylus à étendre» : je ne comprends pas ce que ça veut dire
2. «on vire css modules dans les composants» : je ne sais pas si c'est prévu, quoiqu'il en soit je ne vois pas le rapport avec l'issue encore moins avec cozy-ui. Le fait d'avoir css-modules est une problématique de build et n'a rien à voir avec le code.
3. «on expose plus de class CSS» : on n' expose plus les classes CSS ? On expose + les classes CSS ? Qu'est-ce que ça veut dire "exposer les classes CSS" ?

from cozy-ui.

@enguerran oui, merci encore de ta synthèse ;)

from cozy-ui.