XState : fondamentaux et nouveautés de la version 5

Baptiste est un fan inconditionnel de la librairie JavaScript XState depuis 2020 et il a contaminé Paul sans trop de difficulté. Ils en parlent en long, en large et en travers dans cet épisode. Paul et Baptiste abordent notamment la version 5 de XState qui améliore grandement la librairie, mais aussi du Stately Studio – l'éditeur de state machines en ligne développé par les mainteneurs de XState. L'épisode se termine sur la place toute trouvée de XState dans la création d'AI Agents avec @statelyai/agent.

• Vidéo de Baptiste sur Panda CSS
• Vidéo de Baptiste sur la transformation d'un podcast en vidéo avec Remotion
• Remotion
• React Three Fiber
• XState
• Statecharts
• SCXML
• scion
• XState by Example
• Stately Studio
• Fonction setup() de XState 5
• @xstate/store
• @statelyai/agent

Creators & Guests

Host

Baptiste Devessier

Développeur Web Fullstack en Freelance

Host

Paul Rastoin

Développeur Web Fullstack du Sud de la France

What is Parlons Dev?

Dans Parlons Dev, Paul Rastoin et Baptiste Devessier explorent le monde du développement, du web et de la tech, et parlent des sujets qui les intéressent sur le moment.

Paul: [00:00:00] Eh bien salut à tous, bonjour à toi Baptiste, bonjour à toi qui nous écoute, encore un épisode de Parlons Dev, décidément, on ne s'arrête plus ! Aujourd'hui, rapidement, je vais parler de ce dont on va parler aujourd'hui. Principalement Baptiste va nous faire part de son amour propre pour X-State. Et plus précisément, j'adore X-State aussi, c'est Baptiste qui m'a fait découvrir ça, ça a un bon moment sur un projet d'école il y a deux ans quasiment.

Et j'avoue que c'est une super solution de state management bref ne spoilons pas trop donc on parlera d'Xstate, Xstate V5 mise à jour Xstate et plus globalement aussi de ce que c'est comme techno à quoi ça sert, une petite introduction à tout ça et après on conclura tranquillement que se passe-t-il de ton côté Baptiste en ce moment dans ta vie j'ai cru entendre sur les réseaux que tu avais eu le cadre YouTube des 200 abonnés

Baptiste: Déjà bonjour à tous, et effectivement comme tu le dis Paul, j'ai passé la barre [00:01:00] cruciale des 200 abonnés sur Youtube Waouh, avec zéro

Paul: bot hein

Baptiste: Ça je sais pas, en tout cas pas de mon côté Non

Paul: je t'en ai acheté que 10

Baptiste: Ceux que j'ai payé peut-être utilisaient des bots Voilà, 200 abonnés, bon c'est pas grand chose Mais il y a deux mois encore, j'étais seulement à 60, donc je suis content d'avoir monté un petit peu, en faisant principalement des vidéos sur X-State.

Mais ma vidéo qui a le plus marché jusque-là, c'est la vidéo où je compare Pandas SS et Tailwind SS. Je parle surtout des avantages de Pandas SS. Et voilà, je continue de sortir des

Paul: vidéos. La vidéo-réponse à Théo, du coup ?

Baptiste: C'est ça, Théo T3G, qui avait fait une vidéo de réaction sur un article que j'avais écrit sur Pandas SS comparé à Tailwind SS, et à la fin de sa vidéo, il m'invitait.

Donc répondre à ces points

Paul: j'ai l'impression [00:02:00] qu'on parle de lui toutes les semaines il occupe nos esprits et nos discussions mais non mais c'est très bien et c'est très très cool et tu sais enfin je veux pas que tu leaks trop de data mais tu sais combien d'abonnés ça t'a rapporté ce petit shoutout public

Baptiste: Je ne sais pas combien d'abonnés ça m'a apporté sur les 140 que j'ai gagné en deux mois, mais je suppose 80 ou 90%.

En

Paul: tout cas, félicitations pour ce step. D'ailleurs, tu as sorti une vidéo hier. Sur la construction d'un podcast avec Raymotion.

Baptiste: Alors oui, Raymotion c'est un outil que je suis depuis pas mal de temps et que je trouve absolument génial. Raymotion permet de créer des vidéos avec React. On utilise des composants pour créer une vidéo avec des animations, du son, plein de choses comme ça avec du React.

Et c'est un outil très puissant que j'ai [00:03:00] découvert il y a peu pour justement lors du montage d'une vidéo qu'avec Paul on a tourné avec deux amis. Où on dessinait un vase avec des fleurs en html css et il y avait des passages, je me suis occupé du montage, il y avait des passages de la vidéo où on parlait, on se disait des choses sauf qu'on n'avait pas grand chose de pertinent à montrer à l'écran.

J'ai choisi d'afficher non pas un écran noir, non pas une photo de chat, mais une vidéo faite avec Raymotion où on voit quand chaque personne parle. C'est une grille avec la photo de chaque personne, une couleur différente. Et quand quelqu'un parle, il y a un halo lumineux vert qui s'allume autour de son avatar.

Et ça, je l'ai fait avec Remotion. J'identifiais quand chaque speaker parlait et j'ai généré une vidéo avec Remotion comme ça, que j'ai incluse ensuite dans mon [00:04:00] outil principal d'édition vidéo.

Paul: Tu parlais de TSX, enfin, sauf erreur, tu parlais de créer tout ça dans un contexte React. Est-ce qu'on peut comparer Remotion avec React 3 Fiber

Le truc qui permet de créer dans un Canva directement avec des éléments JSX ou VDSX, peu importe, des entités dans un moteur 3JS ?

Baptiste: Effectivement, on peut le comparer parce que ça permet de créer des choses plus évoluées que juste des divs. Et ce qui est à noter, c'est qu'on peut utiliser TreeJS avec Raymotion pour vraiment faire des vidéos complexes avec des modèles 3D et d'en faire une vidéo.

L'intérêt de Raymotion, c'est vraiment qu'on utilise l'écosystème Écosystèmes React, à savoir que les vidéos, en fait, permettent d'utiliser des technowebs, même du CSS. J'ai utilisé Tailwind CSS pour faire cette vidéo avec... La [00:05:00] grille des speakers, ce qui permet de faire ça c'est que chaque frame de la vidéo est rendu avec Puppeteer dans un dans un chromium et c'est ce qui permet ça.

Donc derrière si tu peux faire quelque chose dans le navigateur En théorie, avec des pincettes, tu peux le faire avec Remotion, parce que ce n'est pas non plus une vidéo sur Remotion et sur X-Tite. On peut changer de

Paul: sujet en réalité, ça me va totalement.

Baptiste: Parlons de X-Tite, mais juste pour terminer sur ce sujet-là, Remotion ne permet pas, par exemple, d'utiliser des transitions CSS dans ses vidéos.

Parce que ça rend en parallèle les frames. Ça spawn plusieurs onglets de Chromium en même temps et ça rend les frames en parallèle. C'est-à-dire qu'une transition qui commence dans un onglet, on ne peut pas utiliser une transition comme ça parce que sinon, elle ne peut pas se terminer dans l'autre. Tu ne peux pas avec les View Transitions

Les view transition [00:06:00] c'est vraiment dans un onglet il y a une transition qui se passe tu peux pas la mettre sur pause tu peux pas la commencer à un niveau précis

Paul: c'était quoi la techno alors qu'on avait vu passer pas mal sur twitter qui permettait entre deux c'était pas des canvas mais tu sais où t'avais une fenêtre qui communiquait avec une autre fenêtre dans une animation ah

Baptiste: Je ne me souviens plus du nom précis de ça, mais Raymotion se base vraiment sur quelque chose de plus simple, c'est que les animations sont gérées en javascript et elles se basent toutes sur la frame actuelle, c'est à dire que tu peux choisir le nombre de fps, 30, 60 et à partir de ça, ça va créer une image, donc ça prend un screenshot par frame et toutes tes animations sont contrôlées en javascript.

Avec une fonction Spring et une fonction Interpolate comme avec Reanimated qui est une librairie pour faire des animations complexes avec React Native et donc c'est vraiment frame par frame, tu peux faire un calcul JavaScript et ce qui te permet donc si tu [00:07:00] gères le screenshot de la frame 29 et de la frame 30 dans deux onglets différents, et bien comme les fonctions JavaScript tu leur passes quelle est la frame actuelle le calcul permet de bien recalibrer et d'avoir une transition smooth, voilà.

Paul: D'accord, alors

Baptiste: voilà

Paul: Ok C'est vachement intéressant, ça sera peut-être un épisode plus complet une prochaine fois.

Baptiste: Clairement, c'est un sujet qui m'intéresse beaucoup en ce moment. On va aller voir la

Paul: vidéo YouTube de Baptiste pour vous faire la main en avance sur le sujet. Je m'activerai, je le ferai activement aussi.

J'ai commencé les 10 premières minutes, je n'ai pas eu le temps de terminer. Bref, je me mettrai un peu au parfum avant cette vidéo-là. Mais en revenant au nerf de la guerre, à savoir X-State, est-ce que tu ne veux pas nous présenter en quelques mots, avec les témo d'ailleurs, qu'est-ce que c'est qu'X-State comme solution de State Management

Baptiste: Oui, mais [00:08:00] peut-être Paul, veux-tu nous parler rapidement d'un sujet qui t'intéresse dans le moment, parce que j'ai un peu monopolisé ce temps. Ah non,

Paul: non, mais vraiment, t'inquiète, je pense qu'on peut enchaîner tranquillement, ça ne me semble pas déconnant.

Baptiste: Très bien. Bon bah écoute, Xtide déjà pour commencer, qu'est-ce que c'est

Xtide c'est une librairie pour créer des state machines et des state charts en javascript et aussi en typescript Mais donc une fois qu'on a dit ça, on n'a pas dit grand chose. Que sont une State Machine et une State Chart ? Une State Machine, c'est une façon de représenter son code en raisonnant par état, événements et transition.

C'est-à-dire que très souvent dans du code écrit de manière non utilisant des State Machines, On a des booléens qui représentent des états comme par exemple si je récupère des données d'une API je vais avoir forcément un booléen isFetching que je vais mettre à trou dès que je vais commencer [00:09:00] à récupérer des données et ensuite je le repasserai à false quand le chargement aura fini je peux aussi avoir des booléens pour représenter si oui ou non il y a eu une erreur pendant le chargement Et en fonction de ces booléens, qui représentent donc des états, il va falloir que je les combine entre eux pour par exemple afficher un loader, pour afficher un message d'erreur si il y a une erreur et que le chargement est fini.

Donc on se retrouve avec des conditions de plus en plus complexes quand on ajoute de plus en plus d'états. Et le gros souci de ça, c'est que les états en fait sont des états combinés implicites. C'est-à-dire que si par exemple j'ai un booléen isLoading Et que je vérifie que celui-ci est égal à true, et que je le combine, donc je fais un opérateur end à hasError qui est égal à true aussi, je combine ces deux booléens pour arriver dans un état.

C'est l'état et la combinaison de ces deux booléens. Et comme je le dis, plus on a de booléens, plus [00:10:00] on a d'états implicites. Je dis implicite parce que il n'y a rien qui marque, par exemple, qu'un état est impossible. Si par exemple, Je passe ma variable hasError à false dès que, enfin pardon, si je la passe à true uniquement quand le chargement est fini, c'est-à-dire que si le chargement est en cours, hasError ne peut jamais valoir true, et bien c'est un état impossible.

On ne peut jamais être à la fois dans isLogging égale true et hasError égale true en même temps. Sauf que ça, il n'y a rien qui le signifie dans le code, donc c'est un état impossible. C'est une règle que le code, on lui a fixé. Et ça peut donner par exemple des bugs si du jour au lendemain, on change cette règle.

Parce que rien ne va garantir que toutes les combinaisons sont gérées dans le code. Et c'est là qu'on introduit les state machines. Les state machines, au contraire d'être des représentations implicites d'une combinaison d'états, sont des représentations totalement explicites. [00:11:00] Et dans une state machine, il ne peut se passer que ce qui est défini explicitement.

Les états, c'est la base d'une state machine. Par exemple, un exemple très basique, c'est, je ne sais pas, on va prendre une promesse. Une promesse JavaScript, elle est soit pending, soit fulfilled, soit il y a eu une erreur. Et ces états donnent lieu à des transitions différentes. C'est-à-dire que par exemple, quand je suis dans l'état pending, Ma promesse peut soit être fulfilled, soit une erreur peut se produire là-dedans.

Et à contrario, quand je suis dans l'état fulfilled, une fois que la promesse, j'ai pu récupérer sa valeur, donc je ne sais pas si j'ai récupéré une... Une donnée d'une API, une fois que j'ai récupéré cette donnée, la promesse, elle ne peut pas être Fulfilled à nouveau. Elle n'a été Fulfilled qu'une seule fois, c'est-à-dire que l'état Fulfilled est un état final.

À partir de ça, il ne peut plus rien se passer. Pareil pour l'état Error. Mais si au contraire, je veux mettre en place un système de [00:12:00] retries et s'il y a une erreur, je veux réessayer jusqu'à ce que j'atteigne maximum 3 retries, Ou alors que j'aborde, et bien voilà, là c'est une stake machine où on représente des états, des événements, et la transition c'est le fait de passer d'un état à l'autre suite à un événement.

Et on peut étendre cette stake machine, une stake machine c'est vraiment des états très simples, Une State Chart c'est plus compliqué, c'est-à-dire que par exemple une State Chart peut avoir des états avec des sous-états ou des états qui soient actifs en même temps, ce qui s'appelle des états parallèles.

Donc une State Chart c'est vraiment la State Machine onStairWidth, c'est la State Machine qui est plus utile qu'une State Machine toute simple. Avec plusieurs comportements intéressants en plus qui permettent vraiment de modéliser des comportements plus complexes et des systèmes qui correspondent plus à ce qu'on voit dans le monde réel.

Et pour terminer, XState implémente les state [00:13:00] charts et par conséquent aussi les state machines en

Paul: JavaScript. Et en TypeScript en

Baptiste: TypeScript aussi c'est très cher à Paul ah oui

Paul: c'est important mais du coup comme tu disais je pense que c'est important de le rappeler à savoir qu'Xstate est une solution qui permet d'intégrer les state charts dans un écosystème dans un framework React Vue peu importe il y en a plusieurs il y a plusieurs utilitaires compatibles Pas Angular, en tout cas c'est pas fait nativement je crois, mais du coup ça suit une norme qui est, sauf erreur, je sais plus de quand date la spec mais c'est peut-être même un peu comme l'AI où ça a déjà été théorisé avant même l'invention de l'ordinateur, si j'exagère un peu le propos, il me semble que c'est quelque chose qui date déjà d'il y a un bon moment, c'est-à-dire que les state machines ça date pas d'hier quoi, dans l'histoire on en trouve partout, beaucoup dans l'embarqué.

Il y a beaucoup de machines qui tournent, enfin de machines littéralement des robots qui tournent sur des state machines et donc c'est des patterns qui ont fait leur [00:14:00] preuve et qui sont fully covered, qui sont entièrement décrits dans cette spectre là et donc Xstate ne va pas la voler, ne va pas de manière au pif venir prendre des décisions spécifiques quant à l'ensemble de la matrice, la matrice est décrite et documentée par un document qui fait foi à la norme state chart.

Baptiste: C'est un principe très intéressant et très important. C'est que les state machines, à la base des state charts, si il y a les state machines, c'est quelque chose de très vieux. Et les state charts sont elles-mêmes des state machines qui ont une spécification qui est suivie par Xstate, qui est la spécification SCXML.

Donc state charts... Et le créateur des State Charts s'appelle David Harrell et il a créé cette notion de State Charts en 1987. C'est très vieux, c'est utilisé dans [00:15:00] de très nombreux domaines de l'informatique.

Paul: Toutes les personnes qui nous écoutent qui sont nées dans ces années-là, écoutez, si vous avez l'âge de la stage art XML, vous êtes de facto vieux de notre discours, ce n'est pas ce qu'on essaie de dire.

On

Baptiste: va être taxé de jeunisme, mais non, effectivement, nous sommes tous les donnés en 2000, 1987. Des

Paul: jeunes pousses, n'est-ce pas ? Non, nous respectons toute personne âgée de la stage art XML. Ah, Jean Bégaï, de la CXML. Ce n'est pas du tout l'objectif.

Baptiste: Oui, parce que David Harrell, en 87, il n'a pas créé la spécification STXML, c'est plus vieux.

Il a vraiment créé un papier mathématique formel sur comment les state charts peuvent être implémentés, comment elles marchent. Et par la suite, un consortium a donc rattaché au W3C, qui a aussi pensé le HTML, le CSS à la base, tout ça, à la base du web en fait. Et ont [00:16:00] pensé les SXML qui sont un peu devenus quelque chose de très important et toutes les librairies qui implémentent des state charts cherchent à suivre la spécification SXML pour qu'il y ait un peu une compatibilité entre elles Par exemple, une librairie JavaScript qui permet aussi de faire des state charts s'appelle Sion.

C'est une librairie plus vieille que Xstate. Et elle est aussi censée suivre la spec SCXML. Mais bon, comme... Comme beaucoup de spécifications, il faut toujours se poser la question entre choisir de la suivre à 100%, ce qui n'est pas toujours facile, et parfois contre-intuitif pour des utilisateurs d'un certain langage, ou alors s'autoriser à déroger la règle pour certaines exceptions.

Vous avez toujours une question qui se pose, et j'ai vu plusieurs fois... Les mainteneurs de X-Tite se posaient cette question, mais je crois que jusque-là ils en sont un peu tenus à la [00:17:00] spécification. Voilà ce que c'est X-Tite.

Paul: Et donc plus techniquement même, XState c'est quoi ? En fait c'est un gros JSON, si on doit le caricaturer, qui contient donc comme tu l'as décrit des états qui entre chacun d'eux, un état qui peut décrire des transitions vers d'autres états, et plusieurs outils, plusieurs leviers qui permettent de runner, peu importe quel type de code, lever des actions, des services, qui permettent d'avoir des side effects spécifiques et contrôlés au sein de ta state machine.

Le tout de manière très déterministique, c'est-à-dire rejouable et anticipée pour la plupart.

Baptiste: Une chose très importante que tu as dite au tout début, c'est qu'effectivement XState a une API déclarative. Et ça ressemble, comme tu l'as dit, à un gros JSON qu'on crée avec des objets nested. Ce qu'il faut savoir, c'est qu'il y a beaucoup de librairies de state machines.

Qui ne se base pas sur cette API déclarative. Il y a beaucoup de librairies de State Machines où pour créer des états et dire [00:18:00] que dans tel état si je reçois tel événement, je vais dans tel autre état, c'est des fonctions. Donc tu dis ma State Machine point dans l'état X quand je reçois l'événement Y, je vais dans l'état W, ce genre de choses personnellement je n'aime pas trop.

Parce que le très gros intérêt de X-State, et qui n'est pas permis par cette manière impérative de représenter ces machines, c'est que c'est plus facilement visible, c'est plus facilement lisible, et surtout ça peut être représenté graphiquement. De manière différente, ça peut être représenté avec des boxes et des flèches.

Ce qui est aussi le choix fait par Stately, l'entreprise développée par David Courchide, le créateur de Xstate, qui a décidé de créer des outils autour des Sleep Machines, autour de la logique applicative, Et ces outils permettent donc de créer des State Machines visuellement et c'est aussi l'intérêt des [00:19:00] State Machines, des State Charts c'est que cet aspect visuel permet aussi à des personnes qui ne sont pas développeurs de comprendre le code mais aussi potentiellement de le maintenir ce qui n'est pas possible forcément avec du code ROS très compliqué avec plein de trucs un peu nerd à la place les State Machines Permettent de visualiser plus facilement le code.

Alors je ne dis pas que les détails d'implémentation sont simples, mais en tout cas, ils sont plus facilement cachables à des personnes non tech. C'est aussi un des avantages.

Paul: Je ne sais pas si c'est... Je ne suis pas sûr qu'il... Selon moi, vraiment, le visualisateur Stakely ne permet pas à un non tech Réellement comprendre le code mais plutôt la résultante du code et ce qu'on attend du code c'est à dire c'est vraiment un pivot entre l'équipe fonctionnelle ou logique métier peu importe et l'équipe tech à savoir quel est le comportement auquel on s'attend comme on pourrait itérer sur un template Figma bien ficelé avec des components et un design system [00:20:00] pas dégueu c'est à dire que tu peux vraiment créer des maquettes un peu dynamiques et interactives Là, c'est encore un peu plus granulaire, c'est-à-dire que c'est vraiment en termes de fonctionnement peut-être interne à cette vue-là.

Ça serait un truc en complément et un peu plus chirurgical à ce template Figma où tu partagerais avec l'équipe peut-être de design, etc., un comportement vraiment très UI, UX que tu pourrais décrire dans une state machine, par exemple du debouncing, du strottling, que tu connais très bien et dont tu as fait des vidéos.

Pour Estate by Example, qui est un site d'ailleurs que tu as créé, qui présente pas mal de templates sur des patterns récurrents et très intéressants. Je vous conseille d'aller faire un tour. Et bref, c'est plein de sujets qui sont très visuels en fait. Bah oui bien sûr c'est en promo, ne pas s'en priver, mais c'est vrai que par contre je suis pas sûr que, enfin tu vois d'expérience, dès que tu demandes à quelqu'un d'ouvrir une console, dès que tu demandes à quelqu'un de faire un copier-coller d'un JSON ou dès que tu demandes à quelqu'un de faire quelque chose qui est dans une CLI, par défaut s'il n'a pas une [00:21:00] position tech il dira non, et même tu ne demanderas pas en fait, tout simplement, mais c'est tout ça pour dire que le visualisator, enfin le visu quoi.

Il est super intéressant pour se mettre d'accord sur le résultat des détails d'implémentation.

Je ne suis pas sûr que sur la gueule de l'implémentation ça ait une réelle plus-value, non, mais il y a toujours des plus-values. Je me perds un peu dans mon propos, mais ce n'est pas non plus magique, c'est ça que j'essaie de dire, c'est un super levier de communication. Entre des techs et des non techs ça c'est sûr et ça permet même à des non techs de faire une proposition en live c'est à dire dans la modification de la machine bah c'est des c'est très c'est non-verbeux quoi c'est du no code tu fais une petite modif si tu connais un peu l'outil voilà il faut se former sous l'outil c'est comme quand tu commences à faire de l'excel bah tu commences à faire de l'excel tu vas sur un site que tu as jamais fait tu le découvres mais tu te fais très vite la main et tu peux être force de proposition et ça sera tout de suite Transmissible à des techs qui pourront même l'exporter, pour l'importer dans [00:22:00] leur code et tester sur leur code base c'est des super leviers d'automatisation

Baptiste: effectivement ça dépend de la boîte dans laquelle tu bosses et si par exemple les personnes non techs sont volontaires à essayer de comprendre comment les choses marchent Je pense plutôt à une petite start-up où tout le monde travaillera un peu sur le même sujet.

Mais pour moi, l'avantage de Xstate, certes, on ne va pas demander à un gars qui fait du marketing de venir coder une machine très complexe, mais comme tu le dis, ne serait-ce que comprendre le code Ça n'était pas vraiment possible avant, les outils visuels, je ne parle pas du no-code ou du low-code, je parle de comprendre le code et comment marche une application, c'est toujours mieux je pense, pour que tout le monde soit en phase et qu'il n'y ait pas de déception.

Pour moi c'est important qu'effectivement On puisse avoir une vue sur le code. [00:23:00] Je pense par exemple, je ne sais pas si j'ai une state machine, quelque chose que j'aimerais bien implémenter pour Excite, par exemple, c'est un exemple sur un vidéo player, comme celui de YouTube. C'est beaucoup plus compliqué qu'on ne le pense, parce que par exemple, si on n'arrive pas à charger les prochaines frames, les vidéo players qui sont assez robustes, arrêtent d'essayer de...

De jouer la vidéo, ils mettent un loading spinner et ils attendent qu'assez de données aient pu être récupérées. Et ce genre de choses c'est compliqué à faire, d'où l'intérêt d'utiliser une state machine. Et si par exemple dans mon équipe on développait un vidéoplayer, pour moi ce serait intéressant que par exemple on puisse spot un bug, je sais pas s'il y a une QA, la QA peut plus facilement identifier un bug, ce genre de choses.

Encore une fois, je ne pense pas que les marketeuses soient le cœur de cible de Stately. Mais par exemple, des designers, ça leur permet d'avoir un pied dans [00:24:00] l'implémentation déjà. Donc l'objectif, c'est juste pour bien résumer ce qu'est cette partie-là de Stately, ça s'appelle le Stately Editor. Et c'est un outil en ligne qui permet donc de créer des state machines visuellement, de les exporter comme du code, mais aussi de synchroniser les state machines construites dans le Stately Studio avec un repository GitHub.

Ça permet donc de générer du code XState à partir de la représentation visuelle, et soit de l'extraire manuellement et de le mettre n'importe où, soit de synchroniser ça avec un repo GitHub. Voilà, donc juste pour clarifier ça, et voilà. Ok.

Paul: Il y a une autre, enfin on a beaucoup parlé de tout ce qui gravitait autour d'XState, mais je ne suis pas sûr qu'on ait vraiment parlé de l'expérience de dev.

En tout cas on n'a pas apporté assez d'importance à ça qui en fait, bah les premières personnes concernées malgré tout c'est les devs au niveau de l'implémentation d'Xstate et de bah de à quoi ça ressemble en fait, c'est ceux qui vont le vivre tous les jours et qui vont faire des modifications, réparer des bugs etc [00:25:00] c'est à dire que Xstate, moi je le compare pas mal Alors à vrai dire, il y a une similitude dans la réflexion et la mise en place d'une intégration avec par exemple TypeScript.

C'est à dire que personnellement avant de commencer à faire une feature ou à bosser sur un sujet, je vais me demander quel est le modèle de données qui va traverser mes différents services, mes différentes fonctions etc. Et je réfléchis d'abord à l'architecture de mes entrées et de mes sorties de typage, je fais mon typage avant de me mettre à coder.

Après je l'adapte bien sûr au fur et à mesure si je découvre des complexités dans le workflow mais c'est un peu la même chose avec Xstate en fait, ça permet de vraiment venir d'abord réfléchir et designer sa machine et ensuite vérifier comment la logique métier qui est contenue dans ma machine je vais pouvoir la transpiler et en faire une vue dynamique mais la vue sera techniquement agnostique, n'aura pas connaissance des sous-jacents conditionnels, spécifiques, régis de manière explicite et déclarative par la state machine.

A savoir aussi qu'il y a une autre plus-value là-dedans qui est que X-State [00:26:00] c'est sa propre spec, c'est-à-dire que si tu veux exporter une machine vers un autre projet, tu fais des migrations de framework, tu fais des migrations d'outils, et bien ça te permet de le faire, si c'est bien architecturé, assez facilement.

C'est-à-dire que dès que tu spawnes un service externe, en réalité c'est un service que tu déclares dans la configuration de ta machine, Derrière pour envoyer un mail que ce soit Seline Blue ou MailChimp ou peu importe service externe tu t'en fous tu peux faire ça sans faire une implémentation X-State je dis pas ça mais en tout cas c'est des leviers d'accélération ce

Baptiste: que ça veut dire c'est que X-State est juste là pour représenter de la logique derrière la façon dont vous implémentez précisément les side effects Pour préciser ce qu'est un side effect, quand je passe d'un état à l'autre, je veux effectuer un changement dans ma base de données, je veux effectuer un log dans la console ou modifier un hook react, ce genre de choses.

Un side effect, [00:27:00] c'est un changement opéré, une action, une fonction qu'on exécute et qui va faire un changement. Qui n'a pas vraiment trait à la définition de la machine elle-même. Et la façon dont on implémente les side effects, mais aussi les parties du code qui sont monitorables, Paul en a parlé un peu plus tôt.

Par exemple, si je veux faire... Si je veux récupérer des données d'une API, c'est quelque chose que je peux vouloir monitor avec la state machine. Par exemple, la state machine dont j'ai parlé au début, qui représente une promesse, je pourrais faire ça pour de vrai. Récupérer la donnée, s'il y a une erreur qui est X ou Y, la gérer différemment.

Donc là, ce n'est pas un side effect dont je peux me... Dont je peux n'avoir rien à carrer c'est quelque chose que je veux moniteur et paul a mentionné ça ça peut s'appeler soit un service soit un acteur dans le monde x

Paul: Oui carrément, [00:28:00] d'ailleurs il y a des complexités, on parlait d'acteurs modèles et d'ailleurs c'est un sujet dont on discutait un peu dernièrement c'est vrai que lorsque tu commences à faire de l'X-State tu vois le potentiel de centralisation, de scoping des différents services que tu peux faire à travers des acteurs qui exposent vraiment plus ou moins une API, c'est à dire une liste d'événements qui peuvent faire muter le state interne et enfin différents hooks qui te permettent d'écouter ce state interne et toi de rendre dynamiquement une vue Après à savoir qu'il faut faire attention à ne pas faire des hasty abstractions, c'est-à-dire parfois spawner des acteurs pour faire un truc qui pourrait être Plus, comment dirais-je, flattened, c'est-à-dire plus plat au sein d'une même machine.

Il faut éviter de trouver par défaut la réponse à ces problèmes dans une complexité d'acteur-model. À savoir, imaginons, je sais pas, l'acteur-model c'est l'idée de, tu spawne une machine qui va peut-être spawner d'autres machines enfants avec lesquelles elle va communiquer, etc. Plusieurs manières d'invoquer des machines, il peut y en avoir des manières Avec une taille dynamique ou [00:29:00] une machine vraiment spécifique pour un job donné, par exemple un formulaire, etc.

Dans ce genre de cas, ça me paraît plus contrôlable que dans le contexte où tu spawnes un nombre de machines indéterminées ou par exemple pour du chat, etc.

Baptiste: C'est vraiment un cas d'usage un peu avancé. Comme dit Paul, le modèle d'acteur c'est un design pattern, ce n'est pas utilisé qu'avec Xstate quand on fait du langage fonctionnel type Rlang.

Ou élixir, c'est quelque chose d'assez présent. Un acteur, c'est une manière de concevoir les choses. C'est une entité qui reçoit des événements pour influencer sur son état interne. On ne peut pas modifier son état interne. Son état interne de l'extérieur par exemple une classe javascript on peut je sais pas si on une fois qu'on l'a instancié on peut venir modifier son état de l'extérieur on fait je sais pas [00:30:00] point x égale 3 et l'état est modifié le modèle d'acteur c'est vraiment pour ce couple et les états et être certain que seule certaines façons peuvent être enfin qu'on ne peut modifier l'état que de certaines façons qui sont bien documentés et Et XState utilise donc ce modèle d'acteur, ça permet de créer des state machines comme le disait Paul avec une liste.

Je ne sais pas si j'ai un exemple un peu tiré par les cheveux et je ne suis pas certain que je le recommanderais. Admettons qu'on développe une application de messagerie avec un chat, Peut-être qu'on peut représenter chaque conversation par un acteur, par une instance de State Machine qui va gérer les nouveaux messages, les messages qu'on envoie, tout ça.

C'est une façon de concevoir les choses et chaque conversation a un état propre et potentiellement, on peut communiquer entre acteurs pour partager des données. Et je ne sais pas si l'acteur A reçoit l'événement, je ne sais pas, Update [00:31:00] Your State, il peut choisir oui ou non de modifier son état interne.

C'est vraiment ce principe-là. De garder les données qu'elles soient scopes et que seul l'acteur décide si oui ou non son état interne peut être changé c'est un principe important avec X-State

Paul: Tu parlais de conditions implicites, c'est-à-dire l'intersection entre par exemple le hasError, un booléen qui décrirait l'état d'erreur d'une vue et l'état loading d'une vue.

A savoir que du coup, pour revenir sur cet exemple-là, XState, par la définition de ses états et des différents événements ou actions qui peuvent être écoutées dans certains états, permet explicitement, Avoid, ne pas écouter certains événements Imaginons un player YouTube Si tu es dans l'état play Tu ne vas pas déclarer Une transition possible Sur la réception d'un événement play Tu es déjà dans l'état play Le seul simple fait de ne pas écouter cet événement Fait que même si Pour X raisons, ta machine venait à recevoir Cet [00:32:00] événement play alors qu'elle ne l'écoute pas Il ne se passera rien Et c'est malgré tout une charge mentale Enfin, une charge mentale en moins.

Au début, on peut trouver ça un peu anodin, mais finalement, c'est une sacrée plus-value.

Baptiste: Oui, et un exemple que j'avais noté pour cette histoire de player vidéo, c'est par exemple, on est sur YouTube. Je ne suis pas certain que ça implémente précisément le comportement que je vais mentionner. Mais en tout cas, on peut imaginer qu'un player le fasse.

Je suis sur un player, je suis dans l'état pause, la vidéo est sur pause, et là j'appuie sur la flèche droite pour avancer de 5 secondes. On peut imaginer que le player décide d'avancer de 5 secondes et de lancer la vidéo instantanément. Et pour ça, c'est-à-dire que dans l'état pause, on représente une transition pour l'événement forward, qui va Modifier l'état de la StateMachine pour faire avancer le timecode de 5 secondes et en plus ça va faire une transition vers [00:33:00] l'état Play.

Voilà, c'est essentiel, c'est essentiel aux StateMachines et comme le dit Paul, on définit avec une StateMachine seulement les transitions possibles Ça n'a pas seulement trait au modèle d'acteur, c'est plus propre au State Machine en elle-même. La State Machine peut choisir oui ou non d'écouter un événement et de se comporter d'une manière X ou Y selon son état.

C'est vraiment l'avantage des State Machines, c'est de choisir comment se comporter dans un état précis, parce que par exemple de l'état A à l'état B, On peut vouloir gérer différemment un événement.

Paul: Oui, de manière conditionnelle ou pas d'ailleurs. Après, il reste à savoir communiquer et interpréter l'état de notre machine.

Et les différentes variables qu'elle nous expose sont contexte, des tags aussi, c'est des étiquettes que tu peux mettre dans certains scopes d'état, etc., qui te permettent d'afficher une vue qui soit intelligente et qui reflète l'état de ta machine auquel tu [00:34:00] t'attends.

Baptiste: Et le contexte, c'est les données de type non fini.

Une certaine machine représente tous les états finis d'une application. Et quand on veut stocker des trucs qu'on ne peut pas représenter par un nombre fini d'états, on stocke ça en contexte, je ne sais pas, les données de l'utilisateur, on ne peut pas représenter dans une state machine que son pseudo ce soit A, B, C, D, etc.

C'est infini. On pourrait parler

Paul: de store aussi, mais ce n'est pas du tout la nomenclature XState, mais pour ceux qui font un peu du Redux, etc. C'est comparable

Baptiste: par rapport à ça c'est très intéressant que tu le mentionnes David Courchide le mainteneur de XState a sorti littéralement hier une librairie XState Store qui permet de créer des stores à la Redux ou à la The Stand JotEye ce genre de trucs c'est pas des state machines pour le coup c'est vraiment des stores, on stocke des trucs dans un objet et ça reçoit des événements pour mettre à jour le contexte quel rapport avec XState alors[00:35:00]

Le rapport avec X-State, c'est qu'on pouvait déjà faire ce genre de choses avec X-State, c'était juste une state machine sans état enfant. C'est vraiment une hybride que David Courchide a sortie hier et qui est un peu niche. C'est quand on a X-State dans son projet, qu'on veut faire des stores, stocker des choses dans un objet de manière réactive, pouvoir écouter les changements.

Et qu'on n'a pas envie d'installer en plus The Stand pour les petits besoins c'est

Paul: sorti sur l'orga Stately ?

Baptiste: oui ça s'appelle X-Site Store je ne sais pas si ça a encore été indexé par Google non Voilà pour X-State. On peut peut-être aussi rapidement parler de X-State 5 parce que c'est un sujet important.

X-State 5, on l'a attendu longtemps. L'équipe de X-State l'a sorti il y a quelques mois. Et le très gros avantage de X-State 5 par rapport à la V4, c'est que la V4 était un peu [00:36:00] centrée sur les State Charts. La V5 permet de créer de la logique, quel que soit leur type, que ce soit des State Machines, c'est un peu la raison de vivre de X-State, mais il y a d'autres types de logique représentables avec X-State, donc à mentionner les Promesses, Les promesses sont des first class citizens avec XSite, donc des choses qui sont gérées nativement.

Il y a aussi des callbacks, c'est-à-dire des fonctions qui permettent d'envoyer des événements à la site machine, de recevoir d'autres événements à la site machine. Un bon exemple pour les callbacks, c'est par exemple écouter un websocket. En WebSocket, ça nécessite l'installation d'une connexion WebSocket et la communication avec l'acteur principal, bref.

Ça gère aussi les observables de RxJS, je sais que Paul joue pas mal avec. Et les State Machines comme je l'ai dit. Plein d'autres choses qui sont maintenant mieux gérées avec XSite 5. Et une autre chose qui va faire plaisir à Paul, c'est le support TypeScript. [00:37:00] Avec la version 4, c'était un peu compliqué.

Paul: C'était tolérable quand même, il y avait un effort.

Baptiste: Oui, effectivement. On a la

Paul: code

Baptiste: gen,

Paul: tstypes.

Baptiste: Voilà, et... L'équipe d'Xstate a dû créer un outil de type generation pour faciliter le typage avec Xstate 4. Avec Xstate 5, pas mal de choses qui étaient apportées par la typegen ne sont plus obligées de passer par une typegen pour les avoir.

Par exemple, quelque chose de très utile, c'est de pouvoir savoir dans quel état d'une state machine on est. Et jusque là, la fonction qui permet de déterminer ça, qui s'appelle matches, Elle n'était pas type-safe, au sens qu'elle n'autocomplettait pas les seuls états disponibles dans la site machine. Avec XSite 5, sans type-gen, c'est possible.

C'est possible grâce à une fonction de setup. Vraiment, ça s'appelle setup. Et je recommande à quiconque teste XSite 5 de [00:38:00] s'en servir. Ça facilite absolument tout. Et il y a plein de choses qui sont typées nativement grâce à ça.

Paul: D'accord. Est-ce qu'il est possible maintenant de fortement typer aussi

Différents échanges entre une machine parent et son enfant

Baptiste: c'est pas encore tout à fait possible et c'est assez compliqué parce que tu peux avoir deux services qui communiquent entre eux de manière un peu hasardeuse c'est un sujet compliqué difficile à typer de manière forte C'est un peu compliqué mais quelque chose

Paul: c'était Don Invo que je ne sais plus le nom du il y avait un générique qui permettait quand même de Je m'en rappelle plus, plus tard, je crois que c'est

Baptiste: DoneInvokeEvent, il y a effectivement des outils dans la V4 pour faciliter le typing de certaines [00:39:00] opérations. Avec la V5, il faut noter que les types sont quand même bien mieux, par rapport à ça, Quand j'ai par exemple une invocation, pour repréciser, une invocation c'est quand une State Machine vient manager, lancer un service, que ce soit une promesse, un callback, une autre State Machine, ça manage son état et cet acteur peut se terminer.

Et dans le cas d'une promesse par exemple, c'est quand la promesse a été résolue. Et X-State permet, avec les types de la V5, d'avoir le type correct de la valeur de retour de la promesse. Et ça, c'est possible directement, c'est assez fort. Sans rien avoir

Paul: à faire ?

Baptiste: Sans rien avoir à faire, mais pour ça, il faut définir son action « inline

Dans la transition, transition on-done pour quand le service est fini et par exemple on peut exécuter des actions pour je sais pas faire un log ou [00:40:00] des trucs comme ça et l'événement, l'objet événement qui contient le résultat de la promesse est fortement typé dans ce cas là. D'accord

Paul: mais tu peux toujours utiliser la déclaration des services dans la configuration tout en bas

Effectivement,

Baptiste: tu peux extraire la définition des services et des actions et de ce genre de choses pour les représenter par un string utilisable plusieurs fois dans ta State Machine. Mais dans ce cas-là, contrairement à ce que la typegen de la V4 rapportait, tu n'auras pas l'événement qui sera narrowed à uniquement les événements possibles.

Mais avec la V5, il y a une fonction qu'avant il fallait implémenter soi-même qui s'appelle assertEvent, qui permet de... ça lève une erreur si au runtime, l'événement reçu ne correspond pas à ce que tu mentionnes. Ok.

Paul: Pour pouvoir permettre à TypeScript d'infer le payload spécifique à l'événement [00:41:00] décrit plus haut dans le...

Dans les schémas

Baptiste: mais pour préciser ça c'est vrai qu'effectivement les types c'est compliqué d'avoir ça qui marche parfaitement et que les types soient fort partout parce que t'es sur une API déclarative un gros JSON et les trucs sont entrelacés, t'as des états enfants bref c'est compliqué quand

Paul: le seul truc qui te relie à ta fonction qui est fortement typé c'est un string du coup quand tu parlais d'inline et tu parlais de référence c'est un string Mais c'est vrai que malgré tout, dès que tu veux réutiliser un service, un guard, peu importe la méthode, tu veux pouvoir la centraliser quelque part.

Après si c'est des choses assez génériques et utilisables partout techniquement, Tu t'en fous un peu de savoir de quel événement tu viens ou alors ça peut être assez général je

Baptiste: pense que de toute manière il y a toujours une liste précise d'événements qui conduisent à invoquer un service, à [00:42:00] run une action mais ce qui est important de mentionner c'est que certes dans ces services dans ces actions on n'a pas contrairement à ce que la typegen apportait on n'a pas connaissance précise de l'origine de l'événement par contre Avec la fonction Setup, la façon dont on définit maintenant ces StateMachines, c'est qu'on appelle avant tout la fonction Setup, on configure ce qui est utilisable dans la StateMachine, les acteurs, les actions, et ensuite on appelle la fonction CreateMachine qui crée la machine.

Et cette fonction, parce que Setup a été appelée avant, a connaissance des seuls acteurs, services qui sont disponibles. Et là où c'est fort, c'est qu'avec la V5, Quand on crée un acteur, il y a la possibilité de définir précisément quelles sont ses valeurs d'entrée, ce qu'ils appellent l'input maintenant, et cet input est typé fortement, et parce que TypeScript a connaissance des acteurs qui sont disponibles, [00:43:00] Xstate lèvera une erreur si l'input qui est Provide ne correspond pas à ce que l'acteur attend précisément.

C'est un gros avantage. C'est

Paul: très cool. En gros, pour être sûr de bien comprendre, tu décris une machine qui attend un argument différent, que ce soit des services, des guardes ou quoi, qui les décrit juste leur prototype. Et donc lors de l'instantiation et de la création du service, l'interprétation du service de cette machine, tu dois lui balancer, tu dois lui provider ces arguments-là.

Soit s'ils ne sont pas là, déjà tu as une erreur, mais ça je crois qu'en V4 ça existait déjà. Mais du coup c'est la signature de ce que tu provides un guard n'est pas compatible avec la déclaration alors il y aura des erreurs

Baptiste: si par exemple j'ai un service je sais pas fetchWeather pour récupérer la météo d'un endroit et que j'attends précisément un objet comme paramètre avec une propriété je sais pas location et bien quand j'invoque cet acteur si je ne reçois pas la propriété location qui soit un string valide et bien ça lèvera une erreur ça me dira il faut [00:44:00] qu'il y ait la propriété location et que ce soit un string et bien ça lèvera une erreur Ah

Paul: non là tu parles, en fait c'est vraiment de l'avéliation des modèles de données au runtime alors

Ah

Baptiste: non c'est que des types c'est que tu dois provide l'impute, que ce soit n'importe quelle valeur, ça peut être un objet ça peut être un string et si tu ne provide pas ça quand tu définis l'impute dans ta state machine et bien ça lève une erreur TypeScript D'accord

Paul: Ok, mais du coup il n'y a plus de code gen dans la V5

Baptiste: Il y a des discussions sur le Discord où peut-être que la taille hygiène serait réimplémentée, mais à mon humble avis, je ne pense pas que ce soit prioritaire du tout. Parce que de mon expérience avec la V5, que je n'ai quand même pas mal utilisée jusque-là, il n'y en a plus vraiment besoin. L'intérêt de la taille hygiène, c'est de ne pas avoir à maintenir, par exemple, des listes statiques soi-même.

Paul a parlé [00:45:00] des tags. Les tags c'est quoi ? C'est chaque état peut avoir une liste de tags, donc un intérêt c'est par exemple, je ne sais pas, j'ai plein d'états qui représentent de la récupération de données ou alors du debouncing, ce genre de choses. Et je peux par exemple vouloir afficher un loader, sauf que je ne veux pas dans mon code avoir à dire j'affiche un loader si je suis dans l'état A, dans l'état A.B pour avoir des états nested.

Je ne peux pas maintenir cette liste moi-même. Dans mon code, ce n'est pas maintenable. Et l'intérêt des tags, c'est dans la state machine, je dis que l'état, je ne sais pas, fetching, il a le tag displaying loader, ce genre de choses, c'est pour centraliser ce genre d'action. Et ça, dans la V5, il faut maintenir sa liste de tags manuellement, il faut maintenir en fait les tags qui sont possibles dans une state machine par une type union de strings.

Littéraux, et ça ça pourrait être automatisé avec la V5 mais d'un [00:46:00] côté soit c'est la typegen qui détecte quels sont les tags utilisés soit d'un autre côté c'est le développeur qui choisit quels tags sont accessibles dans cette machine c'est un peu du kiff kiff quoi

Paul: tu veux dire que tu pourrais vouloir déclarer des tags qui ne soient pas fortement typés

Les

Baptiste: tags, disons qu'avec la V5, tu dois au préalable définir les tags que tu veux utiliser. Et si tu essaies d'utiliser un tag qui n'est pas défini dans tes types, qui corresponde aux tags possibles, ça lève une erreur. C'est l'inverse de la typegen, la typegen est collectée tous les tags définis, là avec la V5 tu définis au préalable les tags accessibles.

Paul: Ça me semble pas déconnant du tout, honnêtement.

Baptiste: Après, si tu as énormément de tags, ça peut être chiant à maintenir.

Paul: Tu peux totalement générer des tags de manière dynamique, non ?

Baptiste: Tu penses à quoi ?

Paul: Avec du JavaScript, peu importe. Enfin, avec des... TypeScript te permet de faire... Enfin, je veux dire, TypeScript de base te [00:47:00] permet de faire des choses de manière assez dynamique.

Tu peux faire de la déclaration qui se base sur plein de choses. Sur des valeurs, ouais.

: Ouais.

Paul: Tu fais des...

Baptiste: Après honnêtement je ne vois pas des use case où tu voudrais que le typescript génère des tags c'est totalement

Paul: overkill et c'est plus un exemple bateau qu'un réel cas d'usage concret de la vie réelle comme

Baptiste: tu le dis c'est effectivement possible et c'est pas une limitation ok Très bien.

Paul: Oui c'est sûr que l'outil ne doit pas forcément couvrir tout ce qui peut être fait aussi de manière idiomatique en TypeScript ou peu importe d'autres outils qui se plug à XState. C'est très bien. Ok, écoute mon cher Baptiste, je sais pas si t'as d'autres remarques ou si t'as d'autres sujets spécifiques à X-State que tu voudrais aborder toujours à ce point là

Baptiste: Je sais que cet épisode va être un petit peu plus long que ce qu'on avait voulu comme limite, mais j'aimerais quand même rapidement parler d'une nouvelle librairie créée par X-State, non pas X-State Store, [00:48:00] la librairie est intéressante mais... En amoureux des state machines je préférais toujours me servir d'une state machine que d'un store mais j'aimerais parler de state liegent qui est une librairie créé pour permettre à xstate de contrôler des llm alors on sort peut-être un petit peu des sujets habituels qu'on traite d'en parlant dev parce que on sort un peu du web development pour parler de Des trends dans l'IA mais les LLM pour rappeler rapidement Large Equal Range Model c'est des modèles d'IA qui permettent d'autocompléter à partir d'un prompt et de données ça génère du texte derrière et les LLM pour s'en servir dans des applications réelles Il y a des outils comme Lenschain, comme Lamaindex qui sont des mastodontes et très utilisés dans ce milieu là pour faire toute la chaîne, toute la pipeline qui permettent à un LLM de fonctionner, que ce soit l'embedding de données dans une base de données [00:49:00] vectorielle, L'extraction de données ou la récupération, ou la création de chains.

Une chain de LLM, c'est j'utilise des modèles qui sont propices à une tâche précise et je peux passer d'un modèle à l'autre comme ça. Et State Legends permet de faire ça avec des state machines. Un avantage des state machines pour ça, c'est que créer des chains, c'est la base des state machines. On peut créer facilement des process, des workflows avec des étapes, des conditions, des branches.

C'est fait pour ça. Et un autre avantage que j'ai, Stately Agent implémente le function calling. Il y a des modèles de LLM comme par exemple GPT 3.5 et 4. Qui supporte le function calling. Le function calling, c'est la possibilité de demander à un LLM d'output, précisément, des... Comme s'il appelait une [00:50:00] fonction.

Si par exemple on a un LLM, on lui dit voilà tu es un présentateur de météo et tu dois me donner la météo si je te donne une localisation. On peut dire au LLM, en plus de ses instructions textuelles, on lui donne un genre de schéma OpenAPI avec la documentation par exemple pour une fonction GetWeather OpenAPI très cher à Paul.

Un épisode bientôt sortira sur ce sujet. Il sera sûrement sorti avant la vidéo sur Xtite, mais tout ça pour dire qu'on donne au LLM des instructions sur des fonctions précises à appeler et les modèles qui ont été entraînés pour répondre à ce genre de besoin pourront sortir quelles fonctions appeler avec quels paramètres.

Donc getWeather, un paramètre location par exemple, le LLM saura le faire et l'intérêt de StakeLegend, C'est qu'on peut représenter ces functions calls par des transitions, par des événements dans un état. Je ne sais pas, si j'ai un état [00:51:00] qu'on va appeler « determine what to do next », c'est l'état initial de ma stick machine, je pose une question à mon utilisateur du genre « que veux-tu faire

Mastate Machines a plusieurs transitions possibles, ça écoute plusieurs événements. Par exemple, « Get access to the customer support » pour avoir accès au service client ou « Talk to the technical support » pour avoir plus des réponses techniques. Selon ce que je vais dire à mon LLM, Telle ou telle transition sera prise par la state machine parce que le state liegent va faire en sorte que la transition avec les paramètres qui auront été définis, je sais pas Technical support, je peux par exemple demander l'agent Eve, Paul ou Jacques, je ne sais pas.

Et si l'utilisateur dans sa question demande précisément à parler au support client Paul, le LLM comprendra ça, ça appellera la fonction [00:52:00] correspondante représentée par l'événement et la State Machine passera à un autre état. C'est un cas d'usage pour un chat, pour représenter ce genre de choses avec des LLM et de contrôler un LLM avec des StateMachines.

Je joue actuellement avec ce genre de sujet et j'en dirai sûrement plus si un jour on fait un épisode plus précis sur les LLM. Mais voilà l'idée. Stakely Agent que je recommande et qui permet partiellement de se passer de long chain. Long chain implémente ce même genre de truc avec long graph.

Personnellement, j'ai utilisé pour l'instant Stakely Agent à la place. J'essaierai sûrement l'angraphe plus tard, mais voilà pour représenter des chains d'agents d'IA avec X-Tite, c'est parfait.

Paul: Très belle description de ce sujet, je vais poser une question un peu banale. J'avais vu passer, enfin je te rappelle au front-end meet-up, David Courchet nous avait fait une démo, [00:53:00] Où il construisait de manière dynamique des machines, et ce sous testo via l'AI.

Il me semblait qu'il avait aussi parlé de X-State Agent, On est d'accord que là ça s'agit vraiment d'un moyen de communication vers un LLM mais pas vraiment d'un outil qui permettrait de générer à la volée une machine à état dynamique c'est vraiment, comment dirais-je, je démarre une interaction avec mon modèle j'en tire une transition qui va être anticipée et déjà prédéterminée plus ou moins avec des paramètres bien sûr soit par mes function calling ou par mes transitions prédéclarées

Baptiste: Alors déjà pour rappeler l'intervention de David Courchide dont Paul parle, il a fait ce talk à plusieurs reprises.

L'idée c'est une steak machine qui représente, si je ne m'abuse, une machine pour faire du café. C'est à ça que tu penses Paul ? David [00:54:00] Courchide a créé une steak machine qui permet de faire différents types de cafés, macchiatos, cappuccinos. Et l'idée c'est, avec un LLM, donner l'instruction de ce qu'on veut et que ça comprenne derrière quelles transitions sont nécessaires à appliquer dans cette machine pour arriver à ce but.

Alors je n'ai pas précisément développé quelque chose dans ce sens-là, donc je n'ai Tout un tas d'explications techniques à donner, mais l'idée c'est, à partir d'un prompt, déterminer quels sont les événements à envoyer dans la site machine pour atteindre un but final. Je ne sais pas développer un Mecato, il faut plus d'étapes que pour faire un expresso, il faut mettre du lait, ce genre de conneries.

Je ne suis pas expert en café, mais l'idée c'est, mon LLM, je lui donne Ce n'est pas tout à fait pareil que StateLegend, je tiens à préciser ça. C'est un concept différent, mais c'est toujours utiliser StateMachine avec l'LLM et avec l'IA. Parce que ce que David Courchil disait [00:55:00] lors de ce talk, c'est que l'IA c'est bien, mais ça a toujours existé, que ce soit des PNJ dans Pac-Man ou quoi, qui sont contrôlés par des StateMachines.

Et les StateMachines ont leur place à jouer avec l'IA générative, avec l'LLM. Et ça permet de contrôler leur comportement pour s'assurer que ça parte pas en couille

Paul: de nouveau j'y connais rien mais si du coup en fait de ce que j'avais compris de cette présentation c'était je pense que je me fourvoyais c'était de la génération enfin c'était de la génération à la volée c'est à dire de manière dynamique au runtime de la state machine et des états qui devaient être créés dans la state machine en fait je pense que là où je me trompais c'était pas de la génération mais c'était plus ou moins du pathfinding dans l'idée où Voilà mon cher LLM, j'ai cette state machine qui l'écrit plein d'états et des transitions avec des recettes plus ou moins, enfin des noms explicites j'imagine au niveau des transitions etc.

Tout ce qui est disponible, je peux mettre du sucre, je peux mettre du lait, je peux mettre de l'eau, je [00:56:00] peux mettre du chocolat etc. Maintenant moi je veux un macchiatto, qu'est-ce qu'il faut comme succession d'événements et de transitions pour me faire mon macchiatto ?

Baptiste: C'est ça.

Paul: Donc

Baptiste: pour parler plus précisément Et je viens de me rappeler.

La façon dont ça fonctionnait c'est qu'en fait le LLM c'est pas lui qui déterminait tous les événements à envoyer à la série de machines pour arriver dans l'état final. L'étape 1 c'était je prends la requête de l'utilisateur et je détermine quel est l'état final. Donc par exemple si je veux un double expresso il me faut deux doses de café, si je veux un macchiato il me faut du lait en plus, ce genre de choses.

Et donc le LLM dans la présentation de David Courchide, on faisait en sorte qu'il retourne l'état final de la site machine et par dessus ça, comme l'a dit Paul, il faut faire un peu de pipefinding et on a utilisé un outil avec Paul dans un projet précédent. Qui s'appelle XStateTest qui se base sur une un autre module de XState qui s'appelle XStateGraph et l'idée de ces modèles c'est de pouvoir [00:57:00] générer le paf le plus le plus court pour arriver à un point x et à partir de ça quand on connaît l'état final la state machine étant finie comme c'est un environnement qu'on connaît Avec des transitions bien définies, c'est assez facile de déterminer quel est le chemin le plus court pour arriver à l'état qu'on souhaite.

Donc c'était ça la présentation de David Courchide, c'est comment joindre le fait de déterminer quel est l'état qu'on va atteindre avec l'intérêt de cette machine qui est que ça permet de définir un système sûr, fiable et qui marche toujours de la même manière. Voilà.

Paul: D'accord. Écoute, je pense que vraiment ça serait intéressant J'évoque l'idée, un format où on fait du pire sur une implémentation que tu peux nous partager en fonction de tes clients, je ne sais pas ce que tu as de dispo, d'une intégration de Stately Agent.

Je suis un gros noob dans tous ces sujets-là, donc ça m'intéresserait carrément de te poser les questions [00:58:00] les plus bêtes possibles. Et ce, avec un support visuel qui serait ton code et un live share. Pas piqué des hannetons quoi. Donc peut-être y réfléchir, je pense que ça serait vraiment intéressant. Ça peut être vachement cool

Baptiste: je suis pas un expert non plus dans le domaine je découvre tous les jours de nouveaux trucs et je me heurte à énormément de problèmes et de questions existentielles parce que ça me parait absolument ça me parait absolument compliqué d'arriver à un résultat qu'on peut mettre en prod avec des LLM pour avoir quelque chose de fiable pour toi et qui réponde à n'importe quel besoin c'est du théorique Mais voilà, donc très bonne invitation, merci Paul, on va organiser ça.

On va en parler, ouais. Ça marche,

Paul: et bah écoute, du coup ça ne tisse que du bon pour la suite. Ceux qui ont encore faim et qui sont toujours là, restez, ne vous inquiétez pas, vous allez bientôt être rassasiés, on va s'occuper de faire une petite vidéo sous un autre format [00:59:00] qui reprendra ces sujets-là et qui abordera des points de vue beaucoup plus techniques.

Baptiste: Un peu de screencasting à deux

Paul: c'est ça, ça roule et bah écoute Baptiste, je te remercie pour toutes ces explications et merci à toi de nous avoir écouté et on se dit à la prochaine dans un prochain épisode

Baptiste: à très bientôt de The Monde ciao