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 ?
- 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.
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.
Rejoins un peu les Shemas Graphql
- Plutot coté Stack AMHA
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.
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.
-
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 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