C’est justement une bonne chose d’avoir plusieurs clients différents : ils répondent à des besoins différents, des goûts différents, ont des failles de sécurité différentes, des bugs différents, dépendent de personnes différentes (tant leurs mainteneurs que ceux de leurs dépendances).
4 Likes
Bonne question et tu as déjà deux bonnes réponses 
J’aimerais apporter quelques précisions :
- Cesium v2 part “de rien” au sens où il part d’une base propre et polkadotjs pour gérer la connexion avec substrate
- si Cesium v1 était “peu performant”, c’était pour beaucoup dû à ce qu’il y avait derrière (Duniter v1 et l’indexeur Cesium+ pod), ce qui n’est plus le cas en v2 car c’est Duniter-v2s et Duniter-indexer. Ensuite, Cesium v2 utilise des dépendances à la fois plus à jour et stables, ce qui est un atout pour le développement, et permet aussi de gagner en performances
- bien sûr qu’il est bon d’avoir de la diversité dans les clients, mais vu la communauté Ğ1, il me paraît indispensable d’avoir une interface qui ne perturbe pas trop les habitudes, donc un Cesium v2 qui soit assez proche de Cesium v1 en matière d’interface
J’ajoute un point à ce sujet pour la prochaine visio dev.
7 Likes
Super @HugoTrentesaux tes retours et réflexions sur Cs2 !
Je pourrais aider pour
- paramétrer un formateur syntaxique plus propre.
- Aussi pour le passage à Angular 16, puis 17 - je suis en plein dedans au boulot. Notamment la gestion des templates est (enfin) plus convivial avec des @if @else etc au lieu des “*ngIf ; else” (Google vient d’annoncer cette nouveauté ce mois ci !)
- répondre à tes questions sur AuthData et account service. Ils ont effectivement besoin d’être revus. Il faut que je m’y replonge pour te répondre…
Sinon :
- l’architecture peut être revue, c’est certain. Notamment j’utilise maintenant d’avantage (et mieux) RxAngular pour gérer les Input/Output des composants, et l’état des services. Nous devrions sans doute revoir cette partie.
@cgeek fais tu encore du Angular au boulot, pour aider sur la conception ? - @cgeek j’avais pensé ‘shared’ d’avantage pour des composants très bas niveau, réutilisables par exemple dans d’autres projets, en dehors de tout “métier”. J’ai déjà du code ce module qui me vient de projets pro. Je les ajoute au fil des besoins.
- Je suis toujours motivé, mais effectivement en manque de temps. Si j’arrive à organiser les prochaines RML en mars ce sera déjà bien
mais je sais aussi que cela me motivera aussi pour avancer sur Cs2.
Prenez soin de vous les amis et merci pour ce que vous faites !
4 Likes
Non je ne fais plus d’Angular, tout juste un peu de Vue 3 (et encore). Si vous l’initiez je saurai suivre, mais pas mettre en place des fondations dans l’état de l’art pour un projet front. Et aujourd’hui ces derniers sont aussi poussés, voire plus, qu’on projet backend.
1 Like
@HugoTrentesaux j’ai commencé à intégrer les modifs de ta branche (qui reprennent celle de @cgeek)
J’ai pu avancé sur ce point la semaine dernière. Je vais pousser des modifications structurelles, qui impactent beaucoup de code.
je préfère vous prevenir, au cas où vous aviez debuter d’autres chantiers sur Cs² ? Redites moi si c’est le cas
Concernant le lancement d’une G1v2 pour les 7 an de la G1, je suis bien motivé par ce défi, vis à vis de Cs² ! D’autant que cela collerait avec les RML à Laval en mars, juste la semaine d’après (du 11 au 15 mars 2024).
voilou
3 Likes
Super si tu fais les changements structurels ! Ça permettra de contribuer plus facilement. Pas de travail en cours pour ma part, si j’en ai je le publie dans une branche. Et le dépôt n’a pas de fork, donc on dirait que personne ne travaille secrètement dessus
on avait déjà la documentation de tous les calls : Duniter | Runtime calls
on a maintenant la documentation de tous les événements : Duniter | Runtime events
Ça va évoluer avec les discussions dans API des événements, mais au moins ça fait une bonne base pratique à utiliser.
Moi aussi, très motivé par ce défi !!
Salut à tous,
Je débarque ici et souhaiterai chercher à contribuer à faire avancer cette version 2, même si je ne connais pas trop angular.
J’ai lu déjà pas mal de choses à propos de duniter-v2s sur ce forum et sur duniter.org, et vu une bonne partie des vidéos de Hugo. Mais, il y a quand même pas mal de choses qui restent un peu floues pour moi pour l’instant.
J’ai la compilation et l’exécution d’un serveur duniter-v2s local fonctionnelles, ainsi que la compilation et l’exécution de cesium2s en utilisant ce serveur. J’ai exploré un peu le code de cesium et fait 2-3 petites modifications localement qui n’ajoutent pas de fonctionnalités mais améliorent un peu le code (du moins à mon avis ^^).
Y a-t-il une sorte de feuilles de route des fonctionnalités à implémenter ? Dans quel ordre ?
Bonne soirée !
6 Likes
I created an account for you on our GitLab : https://git.duniter.org/gma. You should have received an invitation email and should be able to fork or create a branch on clients / Cesium-grp / cesium2s · GitLab. (oups, pourquoi je parle en anglais, je ne sais pas).
Il n’y a pas vraiment de feuille de route, mais @cgeek a ouvert un ticket #142 à ce sujet qui liste déjà quelques points.
3 Likes
Ce qu’on fait sur Duniter-v2s, c’est de systématiquement pousser le travail en cours sur une branche et de créer une MR Draft tant que le travail est en cours. Quand le travail est prêt pour relecture, on n’a plus qu’à cliquer sur “mark as ready” pour retirer le statut draft et éventuellement tagger quelqu’un comme reviewer. C’est assez pratique pour coordonner le travail à plusieurs, je t’encourage à publier ton travail le plus tôt possible.
2 Likes
Merci Hugo pour la création de compte et pour le lien vers ce ticket qui donne effectivement des pistes de choses à regarder.
1 Like
J’ai mis à jour les points de ce ticket, comme je suis en train de travailler sur #141 (stratégie de tests) je vois de mieux en mieux les besoins côté client.
3 Likes
Hum. Je vais voir comment faire. Sinon, peut etre prévoir une visio ensemble, pour que tu me contre les détails ?
Voila j’ai pousser sur /develop. L’architecture est beaucoup mieux à mon gout.
- Notamment pour passer une propriété dans RxState, il suffit d’utiliser une des annotations (maison) suivantes :
@RxStateProperty(): pour générer le code de getter/setter qui écrit/lit depuis RxState- ou
@RxStateSelect()pour déclarer un observable écoutant une propriété du RxState.
C’est super propre ! j’y suis bien content !
- J’ai fait une grosse migration vers Angular 17 / Ionic 7.5.6 => il faut donc :
- passer en node 18
- reinstaller tout (
npm i)
Voilou !
Bon du coup j’ai du code qui ne marche plus, mais je vais retravailler tout ca.
@gma redis moi si tu as des questions.
1 Like
Je vais déjà regarder et tester tes dernières modifs.
Pour ce que dis Hugo à propos des MR, c’est juste faire ce que tu as fais, c’est-à-dire créer une branche avec le dev que tu as fais (perso, j’aime bien préfixer le nom de mes branches avec “feature/” ou “fix/” par exemple en fonction de si c’est le développement d’une nouvelle fonctionalité ou un correctif) et ensuite dans l’interface de gitlab, tu crées une MR en sélectionnant ta branche nouvellement créée en source et la branche où tu voudras merger à terme (la majorité du temps master). Tu peux ensuite marquer cette MR comme Draft, ce qui évite de la merger malencontreusement si jamais le dev n’est pas terminé. Et puis il y a moyen d’assigner un reviewer pour faire revoir le code par quelqu’un d’autre avant de merger, ce qui permet bien souvent de trouver des petites coquilles
Il y a aussi moyen de conditionner la possibilité de merger au fait que les tests en CI passent, ce qui est plutôt une bonne pratique aussi.
2 Likes
Bonjour à tous, moi aussi je suis disponible pour aider avec Cesium v2, je n’ai pas de familiarité avec ce stack en particulier (ionic/angular) mais assez d’experience avec beaucoup de stacks differents comme pour me faire utile relativement vite… plus ça si quelq’un qui déjà connais bien le code comme @kimamila est disponible pour coordiner les contributeurs et nous guider vers quelles taches il fait sense de faire en ce moment.
4 Likes
Je peux être disponible 5-10h pour semaine, et rejoindre quelque session de coordi si ça va aider. (Also as you may have noticed my French is not the best so I may occasionally switch to English).
1 Like
@gma @txels On dirait bien qu’on commence à avoir une belle petite équipe ! 
Je ne sais pas trop comment organiser les choses… voici quelques idées :
- compiler/lancer le projet, éventuellement sur une noeud local (cf src/environement/environement.ts pour paramétrer le noeud par défaut)
- prendre connaissance du code, faire quelques modifs, etc.
- prendre connaissance de la doc Polkadot JS API
- prendre connaissance de la librairie RxState
- définir quelques issues, dans le gitlab, pour que l’on puisses se répartir le boulot
Qu’en dites vous ?
4 Likes
J’ai déjà commencé les 2 premiers points que tu listes. J’essaye de me familiariser un peu avec angular, typescript et ionic qui ne sont pas des technos avec lesquelles j’ai l’habitude de travailler. Je vais prendre connaissance de Polkadot JS et RxState aussi dans les prochains jours. Tout ça demande un peu de temps pour se mettre en jambe ^^
Ensuite effectivement, ce serait probablement bien de créer des issues pour ce qu’il y a à faire et qu’on se les assigne, histoire d’éviter de faire les mêmes choses chacun de notre côté.
4 Likes
Moi comme @gma je suis dans le stage de faire marcher le code localement, lire quelques docs et me familiariser avec les APIs et librairies.
En plus d’écrire des issues qu’on puisse se répartir, ça que je trouve très effectif c’est de faire une session de mobbing/pairing où on attaque une des issues ensemble. Après ça je trouve que tous nous aurons plus d’empowerment pour paralleliser le travail.
1 Like
@gma @HugoTrentesaux j’ai répondu à la MR !3:.
Finalement j’ai fait un merge depuis ma branche, en intégrant les modifs de @gma develop. J’ai mis à jour master avec ces modifs.
Enjoy !
Maintenant nous pourrions travailler sur un gitlab CI pour builder tout ca. J’en ai qui tourne, mais je dois les adapter à Angular 17.
2 Likes
Oi! J’ai essayé de prendre ça (j’ai expérience avec GitlabCI) mais après avoir mis à jour mon repo local, faire les npm install (m’assurer que j’ai le CLI de Angular 17) etc je ne réussis pas à builder.
$ npm run start
Error: src/app/shared/shared.module.ts:16:42 - error TS2307: Cannot find module '@app/shared/loading/skeleton.list/skeleton.list.component' or its corresponding type declarations.
16 import { AppSkeletonListComponent } from '@app/shared/loading/skeleton.list/skeleton.list.component';
Même chose avec npm run build. Peut-être un fichier que manque au git?
Le dossier app/shared/loading/ n’existe pas dans le repo.