The Plan - Githubissues

goldoraf commented 7 years ago

Suite à l'atelier de jeudi et surtout à des discussions avec @kosssi et Claire, j'ai pris conscience que nous souffrons d'un manque d'alignement quant à l'évolution de cozy-ui, d'où un quasi status quo. L'objectif de cette issue est donc d'établir une vision claire pour tous et d'en discuter les détails d'implémentation.

Quels sont nos besoins ?

Arrêter de polluer nos composants applicatifs avec des className={classNames(styles['pho-truc-bidule'], styles['pho-machin-chose']} : l'un des procès fait à React est que JSX remettrait en cause le principe du "separation of concerns" en mélangeant HTML, CSS et JS dans le même fichier. Mais ce principe ne dit pas qu'il faut forcément séparer les langages, mais simplement d'isoler dans des portions de code séparées tout ce qui concerne un aspect particulier, une facette, du code. La bonne façon de faire cette séparation avec React est donc d'isoler dans des composants dédiés tout ce qui concerne l'aspect visuel de l'app (structure HTML requise + CSS, qui peut rester dans des fichiers séparés d'ailleurs) et d'utiliser ces petits composants visuels pour construire le markup des composants applicatifs. Cela améliorerait également la lisibilité du code.
Régler nos problèmes de layout : plusieurs bugs nous posent pb, notamment sous Safari. Je ne sais pas exactement où en est @GoOz dans ses tentatives de résolution de ces pbs, mais nous devons trouver une solution et surtout disposer enfin de composants de layouting communs. Je vous invite donc à partager vos opinions et surtout l'avancée de vos travaux respectifs sur ce sujet.
Disposer d'une bibliothèque de composants d'UI avancés (comprendre : embarquant du comportement et donc du JS en plus de l'aspect visuel, donc DatePicker, AutoComplete, etc...). Jusqu'à présent nous nous sommes débrouillés en implémentant nos propres composants (mais sans penser trop à l'accessibilité :/) ou en utilisant des paquets type react-autosuggest qui doivent être adaptés au thème cozy à chaque fois. Cela nous a pris beaucoup de temps, et certaines applis comme cozy-bank ou cozy-santé vont nécessiter des composants que nous n'avons pas encore.
Offrir à la communauté un moyen d'utiliser autre chose que React et/ou la lib de composants d'UI que nous pourrions choisir, et donc exposer par un moyen quelconque ce qui fait le thème cozy, afin que ces développeurs puissent aisément thémer la lib de leur choix.

Ma proposition

Je vois cozy-ui en 3 couches :

Le thème cozy : il nous faut exposer ce qui fait le visuel cozy sous forme de variables, afin de répondre aux besoins 3 et 4. C'est la condition pour pouvoir thémer facilement une lib externe de composants, quelle qu'elle soit. Et cela pourrait même nous permettre d'intégrer ce thème dans une appli Drive native si la nécessité s'en faisant sentir...

Ces variables doivent comprendre :

les couleurs bien sûr, mais aussi tout ce qui concerne les polices,
les styles de bordure, d'ombres portées, adaptées à différentes tailles standard (par ex. de boutons) : small, medium, large
tout ce qui concerne le rythme vertical de la page : margins, paddings, line-heights, ... A titre d'exemple, voici ce à quoi j'étais arrivé avec Bosonic. C'est évidemment un boulot à faire en étroite collaboration avec Claire, et qui bien sûr ne se fera pas en un jour : il a d'ailleurs déjà été attaqué par @ptbrowne et il conviendrait de s'appuyer sur son travail. Bien que comme @CPatchane, l'avocat des standards que je suis préfèrerais une solution à base de CSS Variables (ce qui nécessiterait néanmoins de pouvoir aussi exporter ces variables sous forme de JS(ON) ), la solution JSON retenue me va très bien dans un premier temps.

Une lib de composants visuels pour répondre au point 1. Je parle ici de composants encapsulant des comportements "standards" en CSS, et qui ne contiennent donc pas (ou très peu et de façon exceptionnelle) de code lié au DOM (gestion d'events, ...) : ce ne sont pas des composants avancés type DatePicker que nous n'avons pas intérêt à recoder nous même. Rebass offre quelques bons exemples : un composant Circle pouvant être utilisé pour les avatars, un composant Arrow utile pour les menus, etc... On peut aussi imaginer un ensemble de composants implémentant des patterns spécifiques avec flexbox, comme CenteredPrompt, FeatureList ou Stream... les possibilités sont nombreuses, et c'est là où un master of CSS tel que @GoOz pourrait s'éclater je pense ;) Une bonne façon de lancer ce chantier serait de s'y mettre à plusieurs un vendredi aprem' pas trop chargé (milieu de sprint plutôt donc).

C'est également dans cette couche que viendrait nos composants de layouting. Mais il nous faut pour cela résoudre les pbs cités dans le point 2, et j'attends donc un état des lieux précis et des solutions possibles de la part des personnes directement concernées (@GoOz ? @ptbrowne ? @kosssi ? d'autres ?)

Une lib de composants d'UI avancés (c'est le besoin 3). Comme je le disais précédemment, inutile à mon avis de réinventer la roue, d'autant plus que c'est un boulot énorme pour faire bien et accessible. @kosssi lorgnait sur react-toolbox, et pour avoir suivi de près le monde des libs de composants d'UI ces dernières années, je pense également que c'est la meilleure solution aujourd'hui. Son seul défaut est qu'il impose pour l'instant d'utiliser sass pour créer son thème, mais gardons à l'esprit que ce ne sera jamais que du glue code entre nos variables et la lib, ce n'est donc pas si grave. Il n'est bien sûr pas envisageable (ni souhaitable) de transitionner toutes nos apps d'un coup vers cette lib, @kosssi se proposait donc de POCer son utilisation sur une appli encore à l'état d'ébauche, en l'occurence cozy-santé. Si la création d'un thème ne pose pas de pb particulier et dès que ce thème est propre et stable pour cozy-santé, nous pourrons l'intégrer dans cozy-ui et petit à petit dans les apps, selon la règle du boy scout.

Y a t-il des points de contention que j'aurais omis de mentionner ? Certains ont-ils des oppositions formelles ? J'attends vos réactions à cette proposition, mais n'oubliez pas de lui donner 5 minutes ;)

GoOz commented 7 years ago

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

Besoins

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 ?
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.
Complètement OK
Complètement OK aussi, jamais perdu de vue cet objectif, même si on est encore loin de l'atteindre à l'heure actuelle.

Propositions

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.
Finalement, sans forcément utiliser ReBass on ferait un truc à la ReBass ?
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

y-lohse commented 7 years ago

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

GoOz commented 7 years ago

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.

goldoraf commented 7 years ago

@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

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.
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

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.
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 !

enguerran commented 7 years ago

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>
  }
}

goldoraf commented 7 years ago

@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 ;)

enguerran commented 7 years ago

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 :

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

goldoraf commented 7 years ago

@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.

enguerran commented 7 years ago

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

goldoraf commented 7 years ago

@enguerran :

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

Ah ben oui tiens :p

y-lohse commented 7 years ago

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 ?)

GoOz commented 7 years ago

@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.

enguerran commented 7 years ago

@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

goldoraf commented 7 years ago

@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 ?

GoOz commented 7 years ago

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

goldoraf commented 7 years ago

@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

GoOz commented 7 years ago

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

ptbrowne commented 7 years ago

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
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).
OK pour react-toolbox avec un thème à la Cozy.
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.

GoOz commented 7 years ago

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 :)

ptbrowne commented 7 years ago

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 🙂

goldoraf commented 7 years ago

@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.

ptbrowne commented 7 years ago

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>

goldoraf commented 7 years ago

@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/

ptbrowne commented 7 years ago

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' /> ?

kosssi commented 7 years ago

@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.

CPatchane commented 7 years ago

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à".

ptbrowne commented 7 years ago

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.

ptbrowne commented 7 years ago

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 :)

GoOz commented 7 years ago

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.

ptbrowne commented 7 years ago

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

goldoraf commented 7 years ago

@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.

enguerran commented 7 years ago

@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 :

«on vire les classes stylus à étendre» : je ne comprends pas ce que ça veut dire
«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.
«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" ?

enguerran commented 7 years ago

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

goldoraf commented 7 years ago

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

cozy / cozy-ui

The Plan #195

Quels sont nos besoins ?

Ma proposition

Besoins

Propositions

variables et conventions

implémentation css des classes de base

un styleguide autogénéré servant de doc

une bibliothèque de composants visuels

Enfin une bibliothèque de composants fonctionnels