Packaging D'expérience, gérer plusieurs package c'est galère (la joie de faire 3 npm publish pour corriger un bug) Si on duplique le code entre cozy-client-js & cozy-client, cozy-client-js va diverger et pourrir, mais c'est dommage de se lier à 100% avec Redux+React (qui introduit des concepts pas évidents pour les habitués d'autres FrameWorks) --> monorepo avec cozy-client-js & cozy-client ?
<3 Apollo & GraphQL
- Si c'est vraiment la solution, on peut aussi évaluer l'ajout d'un endpoint graphql à la stack plutot que de re-engineer 3 niveau d'abstraction.
JSONAPI Si on reste sur la JSONAPI, à la base on l'a quand même choisi pour le coté standard et la gestion des relations. Peut-être manque-t-il certains support d' ?include coté stack pour ne pas avoir à rajouter de la complexité coté client sur les references / partage / ect.
Gestion des doctypes Rejoins un peu les Shemas Graphql
- Plutot coté Stack AMHA
Intégrations Redux
Je suis heureux de voir qu'on a toujours les même galère depuis l'époque d'email & la V2, j'ai moins l'impression de m'être chier à l'époque.
Pour en revenir au besoins de bases :
- Besoin d'unifier les données entre pouch / stack (+ realtime)
- Besoin de stocker les infos en RAM dans un store normalisé
- Besoin d'un équivalent mapStateToProps pour passer au composant les valeurs dénormalisés dont il a besoin pour se render (voir reselect)
- Besoin de gérer le fetch de certaines data si on les a pas, quand on affiche un composant qui en a besoin, avec l'éternel problème de ne pas dispatch pendant le render.
- Besoin de faire des actions.
- Si realtime, besoin de gérer des requêtes en vols. Ie appliquer les actions coté local également en attendant qu'elle soit active coté serveur.
Analyse :
Je trouve que le mélange du mapStateToProps et des fetch Action rend la chose pas clair et je suis pas fan des actions injectés automagiquement en fonction de la collection.
Proposition :
-
Soit on admet que la programation fonctionnel c'est pas naturel et on part sur de l'OOP avec un objet collection (~ Promise<Immutable.List<Immutable.Record>> ?) qui contient du coup l'information de fetchStatus et les actions.
-
Soit on sépare le mapStateToProps des fetchActions, par exemple en pseudo code explicité :
AlbumPhoto = ({album, fetchStatus}) => {
}
AlbumPhoto.dataNeed = (props) => {
NAME: 'fetching-album-' + props.id
album: cozy.fetch('album', {id: props.id})
sharings: cozy.fetch('sharings', {shared_id: props.id})
}
cozyConnect(
mapStateToProp: (state, props) ->
album: cozyselect(state => state.albums[props.id])
fetchStatus: cozyselect(state => !state.request['fetching-album-' + props.id].done)
},
)(AlbumPhotos)
DSL DSL de requêtage : si on trouve mango trop compliqué, peut-être mieux de l'abstraire au niveau de la stack (et gérer certains trucs qu'on doit faire en mapreduce) (wink GraphQL) plutot que de rajouter