Super, ça marche ! Merci @cgeek 
Cesium connecté avec le compte Alice sur un réseau local
Maintenant, au boulot ^^
2 Likes
Ce n’est pas propre pour l’instant parce que je ne me suis pas approprié la structure du projet, mais j’ai ajouté l’affichage de la clé publique v1 et de l’adresse ss58 dans le formulaire de login v1 :
C’est sur ma branche hugo-dev. Je continue à expérimenter, on verra ce qu’on en fait après.
4 Likes
J’ai aussi ajouté une POC pour se connecter à l’aide d’un mnemonic (à essayer par exemple avec le compte Alice (bottom drive obey lake curtain smoke basket hold race lonely fit walk//Alice) et ai quelques observations :
- j’ai beaucoup de warnings de lint et de formatage, ce serait bien de préciser lesquels utiliser pour faciliter le boulot à plusieurs
- je comprends l’idée de séparer login et register au niveau de l’interface utilisateur, mais pas au niveau du
account.service.ts. - il y a de la répétition de code entre
createAddressetregister, et je manque de docstring pour pouvoir refactorer ça en restant dans l’esprit duaccount.service. - je ne comprends pas bien la structure du code : pourquoi le
account.serviceutilise à la foisRegisterData, un type du moduleregisteretAuthData, un type du moduleauth? Est-ce que ce ne serait pas mieux de se mettre d’accord sur un type unique et une API claire pour faciliter la gestion ?
En fait je me retrouve comme sur Ğcli au départ : devant un design que je ne comprends pas et avec une conception personnelle de ce à quoi ça pourrait/devrait ressembler. Pour Ğcli j’ai fini par complètement transformer l’architecture, en prenant soin de mettre des docstrings partout pour dire comment s’en servir, et je l’ai fait en sachant que je serai dispo pour assurer le support et la formation de futurs devs sur Ğcli.
Sur Cesium v2 je pourrais aussi entreprendre une grosse refacto pour me sentir plus à l’aise pour développer dessus, mais :
- je ne connais pas du tout Angular, ce que je ferais ne serait probablement pas idiomatique
- ça risque de me prendre un peu de temps, je ne suis pas sûr que ce soit une bonne utilisation
- je préfère me concentrer sur Duniter v2s, l’indexeur, et Ğcli, et ne pas occuper une position centrale sur une trop grande partie de l’écosystème
Au vu des avancés sur Duniter et l’indexeur, j’ai l’impression que Cesium v2 pourrait devenir le facteur limitant pour une migration de la Ğ1. D’un point de vue gestion du projet, j’aimerais avoir une idée de la date à laquelle on pourrait avoir un MVP pour Cesium v2, d’où mes expérimentations ci-dessus. Tant que le projet n’avance pas, difficile de se faire une idée, mais il suffirait d’une ou deux personnes qui y travaillent petit-à-petit dessus pour être rassuré de ce côté et concentrer mes efforts sur le futur live network afin de débugger, tester, et consolider le coeur (il reste des gros bugs comme #129 par exemple).
4 Likes
Peut-être parce que dans les deux cas on a un compte à la fin, et que tout l’application repose sur l’utilisation d’un compte. Par contre je trouve le service account.service.ts bizarrement positionné dans la hiérarchie du code. Je l’aurais plutôt vu dans shared/services/.
Moi non plus, mais comme tu dis Cesium v2 va bientôt devenir le facteur limitant. Et si @kimamila n’a plus de temps ou de motivation, nous serons bien obligés de le faire. En mode MVP dans un 1er temps bien sûr.
Mais c’est d’ailleurs un bon exercice de développer un client pour s’assurer que l’on a rien loupé côté Duniter.
Une idée comme ça: Pourquoi ne pas développer un client à partir de rien? Tout propre, il se servirait des paramètres et des variables de la V2 et serait optimisé. Au mieux, cela ferait un client performant, au pire cela ferait une concurrence loyale.
C’est le cas de Ğecko. Effectivement peut-être vaut-il mieux soutenir ce projet d’autant que son auteur de Ğecko semble motivé et actif !
2 Likes
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