The Plan

[enguerran]

Nous sommes plusieurs à nous poser la question de l'avenir de notre bibliothèque de connexion à la stack gozy. Quel est le plan ?

[EDIT 19-10-2017]]

Je reprends les informations données par @goldoraf :

objectif

Une bibliothèque d'accès à la stack composée de 3 étages :

• étage 1 : gestion de token, API stack
• étage 2 : persistence, normalisation
• étage 3 : Higher-Order Component pour (p)react et autres

feuille de route

• [ ] conserver cozy-client-js le temps de sortir une première release complète
• [x] renommer redux-cozy-client en cozy-client
• [ ] identifier et isoler les 3 couches pour permettre des releases ou pas incluant l'étage voulu (et les étages sous-jacents)
• [ ] sortir une release avec semver, changelog et CI (donc tests)

[gregorylegarec]

Nous venons justement d'en discuter avec @goldoraf, mais je vais le laisser répondre pour ne pas trahir sa vision. Nous avons aussi discuté de ce point:

Nous sommes plusieurs à nous poser la question [...]

On va essayer de mettre en place au prochain sprint de quoi clarifier la vision technique globale des différents sujets qui impactent les équipes front. Si ça marche on devrait tous se poser moins de questions pour la suite.

[enguerran]

J'ai mis à jour le commentaire pour plus d'explications.

[gregorylegarec]

Je ping @sebn tant que j'y pense. Il me semble que les évolutions de cozy-client-js le concernent lui aussi directement, dans la mesure où cozy-client-js est utilisé côté desktop.

[sebn]

Ça me semble être une bonne idée. Par contre je pense que vu l'impact il faudrait en parler plus largement.

[enguerran]

@sebn a écrit :

Par contre je pense que vu l'impact il faudrait en parler plus largement.

Est-ce que tu peux être plus explicit ?

• Que veut dire "vu l'impact" ? Vu l'impact de quoi ? Du plan à venir pour les libs js ?
• Qu'entends-tu par "en parler plus largement" ? Au-delà de nos équipes ? En réunion plénière via une visio-conf ?

[sebn]

J'essaie de clarifier :

vu l'impact → L'impact de la suppression de fonctionnalités de notre principale lib JS.

en parler plus largement → À une audience plus large. Dans le doute je dirais tout le monde en interne. Au delà de nos équipes dans un second temps si ça touche réellement d'autres gens que nous.

C'est mieux ?

[enguerran]

Oui, ça me permet de rectifier quelques ouïe-dires :

1. il n'y a pas de « suppression de fonctionnalités de notre principale lib JS » ;
2. l'idée est justement d'utiliser les issues github pour permettre une communication large et sans qui proquo, permettant d'avoir un historique de discussion et une transparence maximale.

Concernant le point 1. :

• le support de v2 : sauf erreur de ma part, il n'y a pas de rétrocompatibilité qui fonctionne, donc autant alléger la codebase.
• la persistance locale (aka offline) : cette fonctionnalité serait simplement déplacée dans une lib de plus haut niveau. Les responsabilités des deux libs citées dans le post initial sont :
  1. cozy-client-js : une lib API du serveur (avec quelque chose comme une route HTTP -> une fonction JS) permettant de faire des outils comme un client CLI, une app express/node, etc,
  2. redux-cozy-client (qui serait renommée) : une lib plus haut niveau qui permet d'avoir des fonctionnalités pour les web app (persistance, fonctions multi routes (sharing, intents, etc.), etc.)

Est-ce que ça te parait convenable ? Si non, que proposerais-tu pour The Plan ?

[sebn]

Merci pour les précisions.

J'imaginais les critères de découpage suivants :

• Fréquence et contexte d'utilisation
• Dépendances, notamment pour un usage avec des technos autres que celles utilisées par les apps Web Cozy
• Maturité / complexité de chaque API

Avec le peu de vision que j'ai actuellement, j'aurais séparé principalement le support offline et le middleware redux, sans toucher au partage et aux intents pour l'instant. L'offline et la partie redux sont d'ailleurs probablement les fonctionnalités qui ont le moins de chance d'être utilisées prochainement côté desktop, ce qui n'a bien sûr aucun lien 😛

Bref, pour y voir plus clair, je crois que je ferais surtout un état des lieux des apps / clients et de ce qu'ils utilisent / pourraient utiliser. Mais vous avez probablement une vision plus claire que moi là-dessus vu que vous touchez à la plupart des apps en question.

[nono]

le support de v2 : sauf erreur de ma part, il n'y a pas de rétrocompatibilité qui fonctionne, donc autant alléger la codebase.

Ping @aenario

[goldoraf]

Merci de votre patience, je vais m'efforcer de clarifier mes intentions au maximum.

A l'origine, l'idée de redux-cozy-client était simplement de nous épargner tout le boilerplate que nécessite l'utilisation de redux dans nos apps, en particulier nos créateurs d'actions asynchrones un peu lourdingues.

L'objectif final, fortement inspiré par React-Apollo, est de disposer d'un Higher-Order-Component pour wrapper certains composants en déclarant les documents dont ils ont besoin, et que ce HOC prenne en charge le dispatch des fetches d'une part, et injecte des props dans le composant avec les data demandées, plus des indicateurs de l'état des fetches, plus des actions liées aux données (fetchMore, createDocument, ...). La doc, qui nécessite encore d'être étoffée, donne quelques exemples d'utilisation.

Bien sûr, même s'il est très intéressant pour nous de disposer ainsi d'une lib taillée pour (p)react, d'autres développeurs pourraient vouloir utiliser une autre lib, et c'est pour ça qu'il a toujours été clair dans mon esprit que redux-cozy-client ne devait être qu'une surcouche à cozy-client-js. A noter également que redux en soi n'est pas lié à react, et peut donc s'utiliser avec d'autres libs (certains le font avec angular notamment).

Dans sa première version, on maintenait donc simplement dans un store redux le state des fetches en cours de cozy-client-js, et le résultat de ces fetches (les data) sous une forme normalisée.

Et puis, compte tenu de certains petits défauts de cozy-client-js et/ou de l'API côté stack qui me ralentissaient (essentiellement un manque d'homogénéité dans les réponses), j'ai fini par mettre un wrapper au-dessus de cozy-client-js, dans le but de documenter d'une certaine façon ces défauts afin de les corriger ultérieurement. Puis est venu le moment de l'implémentation du partage, et comme nous ne savions pas trop où nous allions au début, nous avons préféré laisser le code se stabiliser avant de l'intégrer à cozy-client-js. Enfin, tout récemment nous avons dû retravailler sur le offline, et l'avons réintégré à redux-cozy-client car l'organisation actuelle de cozy-client-js n'est pas idéale pour y intégrer le offline (il faudrait des ifs partout à moins d'un refacto majeur). Voilà pour l'état des lieux, du code en tout cas.

Pour des raisons de simplicité vis-à-vis de la communauté, il parait préférable de n'avoir qu'une seule lib à mettre en avant, dont le nom serait simplement cozy-client, et dont certaines parties (la couche redux, le offline) seraient optionnelles. On pourrait voir ça comme un cozy-client-js v2, en 3 parties : un client pur proche du cozy-client-js actuel mais corrigeant ses quelques défauts, une surcouche redux de state local, et un binding react (cozyConnect), en attendant de développer des moyens de connexion à d'autres libs.

Ma proposition donc, afin d'aboutir au plus vite à ce résultat, tout en nous laissant le temps de laisser la lib mâturer, et de ne pas forcer tout le monde à migrer tout de suite, serait de laisser cozy-client-js en l'état (modulo les éventuels correctifs/new features absolument nécessaires tout de suite) et de tranquillement en rapatrier le code par petits bouts façon puzzle dans redux- cozy-client.

What do you think of this @enguerran @gregorylegarec @sebn (et les autres) ?

[enguerran]

Ça me parait très bien 👍

Découpage de cozy-client en 3 couches :

• cozy-client-stage1 : API server
• cozy-client-stage2 : persistence, standardisation, etc.
• cozy-client-stage3 : HOC, middleware

Donc ça nous fait 3 étages comme le Soyouz.

J'ai mis à jour le commentaire d'origine pour tenir compte de ces nouvelles informations.

[gregorylegarec]

Idem, très bien. 👍 Et c'est super de le documenter ici.

[enguerran]

Je crois savoir que @goldoraf travaille sur la documentation : un document de référence doit voir le jour bientôt https://trello.com/c/RJPglgIH

C'est pour cette raison que je ferme l'issue. More to come, stay tuned!