Bonjour à tous et bienvenue dans cet épisode où on va parler de Inertia.
Alors pour le coup c'est vraiment Patrick qui va s'y coller parce que
l'expertise PHP dans le duo c'est clairement toi Patrick. Donc tu vas nous
parler d'Inertia, pourquoi c'est super intéressant, pourquoi c'est super
puissant, pourquoi c'est rapide à mettre en place et pourquoi tu es totalement
convaincu par cette technologie. Déjà comment vas-tu Patrick ?
Ça va bien et toi ? Ta forme ? La saison se passe bien ?
C'est le ski, c'est cool. Le ski c'est cool, le code c'est encore mieux et quand on fait les deux c'est
juste parfait. Donc non, c'est vraiment pas mal.
C'est le premier épisode de l'année, mais surtout demi-année. Exactement,
c'est le premier épisode qui vient déclencher 2026. Évidemment encore là on va
continuer à faire des épisodes, des épisodes de news, des épisodes
pédagogiques, un peu comme aujourd'hui on vient présenter des technos. On va
continuer aussi à aller plus en profondeur sur des concepts un peu plus
globaux qui sont propres à notre métier. Évidemment on va continuer
de parler d'IA, de vibe coding et de toutes ces termes qui bougent
énormément, mais en tout cas qui viennent changer fondamentalement
notre manière de travailler. Et je pense qu'il y a des trucs plutôt pas mal qui
arrivent. On continuera à en parler de toute façon.
Disons qu'en termes de news en ce moment, c'est principalement IA, IA et IA.
Et en niveau dev c'est vibe coding à fond. Il n'y a que ça dans le flux.
Donc pour une fois on va parler de code et pas d'IA.
Je sais qu'il y a des gens qui en ont un peu un peu en ralvo d'entendre que de vibe coding.
Et puis surtout je pense qu'on fera un épisode sur le vibe coding ou
qu'est ce qu'on met derrière et qu'est ce que ça veut dire parce qu'on entend
tout et n'importe quoi et ça me paraît important de définir qu'est ce qu'on
entend derrière cette définition. Qu'est ce qu'on y met en fait ?
Parce qu'on fera un épisode dessus d'ailleurs.
Pour l'instant aujourd'hui on va parler d'inertia.
A limite, est-ce que je peux te laisser un peu présenter ce projet là pour ceux qui
ne connaissent pas ? On va dire pour quelqu'un qui est néophyte sur cette
technique, qu'est ce que ça amène et à quel type de profil de dev c'est vraiment dédié
cette technique ? Tout à fait.
C'est un système qui permet de...
En gros, pour partir, on parle d'un système monolithique type la Ravel,
enfin un framework en fait type la Ravel. Alors c'est pas uniquement réservé à PHP et la Ravel.
Il y a différents frameworks qui fonctionnent avec, notamment Django,
il y a Ruby qui fonctionne, Ruby on Rays, donc la Ravel.
Il y a aussi le framework JavaScript qui s'appelle, qui n'est pas de l'ailleurs
présenté sur la homepage d'inertia.
J'ai un trou, rappelle-moi.
L'équivalent de la Ravel en GES, c'est...
Tu l'as ? Non.
Non, je n'ai pas.
Oui, le profil MCP...
MCP classique là, ouais je vois.
Donc il y a aussi un framework...
MCP, MVC, le framework MVC.
On peut aussi faire du GES derrière, on peut faire du Python, du Ruby, du PHP.
Donc c'est pas réservé que à la Ravel et c'est vraiment multi-framework.
Et ensuite, en front, donc ça permet de gérer le bac, le front,
et au niveau front, on va avoir du Vue, du React, des Ducevelt, officiellement.
Et après il y a d'autres adaptateurs, mais ça c'est vraiment les trois techniques
qui sont supportées par Inertia, vraiment officielles.
Donc vraiment, si vous êtes plutôt react, il n'y a pas de problème,
ça marche plutôt vu, enfin, ou les deux, enfin, ce que vous voulez.
Donc c'est vraiment intéressant.
Et pourquoi cette techno existe tout simplement,
souvent, quand on veut faire un front en GES, avec du Vue, du React,
on est obligé de faire, bon, on fait la partie front, donc dans un projet spécifique.
Et ensuite on va faire une API derrière, un bac où on va pouvoir appeler.
Donc ça fait que ça fait un double travail en fait.
On est obligé de faire le développer le back-end avec les routes, API, tout ça.
Et ensuite au niveau du front, on va appeler l'API, récupérer la réponse, la fichette, etc.
Donc tout ça, ça fait double travail, c'est un peu compliqué.
Et quand on est une petite équipe ou un développeur tout seul, c'est double travail.
Donc ça se passe souvent comme ça.
Et Inertia, ce que ça apporte, c'est que ça apporte une unification entre le bac et le front.
Et on se retrouve en fait sur un seul projet, à pouvoir gérer les deux et gérer les appels, tout ça.
Enfin voilà, je vais vous expliquer après comment ça fonctionne, mais c'est assez magique en quelque sorte.
Mais voilà, ça permet de simplifier les choses,
il n'y en a plus besoin de faire des appels, reste GZN, tout ça.
Ok, donc en clair, est-ce qu'on pourrait dire que ça vient substituer le développement d'une API
en créant un contrôleur qui va gérer de manière un peu automatique toutes les entrées et toutes les sorties
JS et quelque soit à ton langage.
Donc en fait, dans ton pattern MVC, le C de contrôleur, Inertia va se venir se brancher sur ses contrôleurs
pour venir injecter, récupérer le JavaScript directement.
Et on va pouvoir utiliser les données dans nos vues,
quelque soit le framework JS qu'on a choisi, c'est ça ?
Ça vient faire cette connexion en fait, c'est ça ?
En fait, ça supprime totalement la pays.
Et du coup, toutes les data sont envoyées par le contrôleur de la Ravel par exemple,
et sont injectées en tant que props dans ton tapage directement.
Tu n'as plus besoin de faire une requête à JAX, c'est directement injecter dedans.
Et ainsi de suite au niveau du fil de route que tu vas cliquer sur un lien.
Ça va aller chercher les props et les injecter, etc.
Donc c'est vraiment automatique.
Et donc tu n'as plus besoin du tout de ta pays, plus besoin de faire des appels à JAX,
quoi que ce soit de récupérer les props, etc.
Donc ça enlève toute cette partie-là.
Et après il y a plusieurs avantages puisque derrière,
alors moi j'ai plutôt travaillé avec la Ravel,
mais c'est exactement la même chose pour n'importe quel framework.
Derrière, on profite des avantages du BAC,
c'est-à-dire tout ce qui est middleware, de sécurité, authentification, etc.
Donc tout ce qui est authentification ne passe plus du tout par le front,
mais passe par le BAC, par le framework, la Ravel ou Rubik.
Donc c'est pas mal d'avantages à ce niveau-là.
Et souvent, je lis et j'entends, c'est magique,
parce que ça marche dans les deux sens,
c'est-à-dire que ça marche aussi bien du BAC vers le front,
mais sur l'envoi d'un formulaire,
ça va aussi envoyer du front vers le BAC,
ça marche vraiment dans les deux sens.
Tu valides ?
C'est ce qu'on va avoir après au niveau du code,
mais il y a pas mal de components qui sont développés,
parce que du coup, tu as un package qui s'installe au niveau BAC,
donc avec Composeur, si c'est du PHP.
Et après tu as un package niveau front avec NPM,
qu'on va ajouter.
Et donc là, on a des composants qui sont disponibles,
notamment le formulaire.
Et le formulaire va envoyer les data au BAC,
et c'est le BAC qui va gérer la validation des data.
Et si ça ne passe pas ce qu'on veut,
ça renvoie les erreurs et ça va s'afficher au niveau du formulaire.
Donc toute cette partie-là, on n'a pas la géré.
Et on valide les data envoyés par le formulaire
que au niveau du BAC,
donc du coup, on évite ces doubles validations en front, BAC, etc.
Donc il y a plein de choses comme ça qui font qu'on gagne énormément de temps.
Et on simplifie les choses.
Nice.
Et c'est Free2use, tout ça, là ?
C'est quoi comme licence derrière ?
Est-ce que t'es obligé de payer un open source ?
C'est Open Source.
C'est Open Source, c'est totalement Open Source.
C'est maintenu par une communauté,
plus les gens, beaucoup pour la ravelle en ce moment.
Mais non, c'est totalement Open Source,
il n'y a pas à payer rien du tout.
Et on peut contribuer évidemment.
Toujours.
Et toi, tu l'utilises déjà en production.
Ça fait déjà longtemps que c'est en place,
comme le projet a évolué, ça ne sort pas du chapeau.
Ce n'est pas un nouveau projet.
Moi, j'ai un site en production qui vient de sortir.
Et puis j'ai un autre gros site intranet qui va sortir prochainement,
qui n'est pas encore en prod complète,
mais qui est déjà un gros truc.
Et c'est notamment pour ce type.
Alors oui, on va quand même détailler
pour quel type de projet ça s'adresse.
C'est principalement à la base,
ça gère le SSR,
donc on peut générer un système SSR
pour générer le HTML pour le serveur.
Et après, ça hydrate l'application fonte.
Mais moi, je trouve que c'est plutôt adapté
pour tout ce qui est un système où on va se connecter.
Et après, on va avoir une sorte de bac, administrative,
on n'a pas besoin forcément d'un SSR.
C'est là pour moi où c'est le mieux adapté,
parce que la partie SSR est bien gérée par Inertia,
mais je trouve que c'est un peu too much.
Il y a d'autres techniques qui s'adaptent un petit peu plus à ça.
Et pour avoir, et je vous ferais voir aussi,
qu'on peut mixer.
Alors c'est l'avantage aussi, c'est qu'on peut mixer,
par exemple dans un projet de la Ravel,
une partie Inertia et une partie classique avec du HTML.
Ok.
Et toi, tu vois le vrai bénéfice ?
Il est sur quoi ?
Il est sur la vitesse de déploiement d'une solution,
la fluidité dans le dev, le confort de dev,
ou la vitesse d'exécution et de mise en place de fonctionnalité ?
La simplification, en fait.
Déjà, quand tu es sur un projet de la Ravel,
tu profites déjà au niveau du pack de tout l'écosystème de la Ravel.
En plus, il y a beaucoup de packages qui permettent d'aller assez vite,
tout ce qui est authentification, gestion des droits, etc.
ou même paiement avec ce travail tout de même.
Tu as un écosystème qui est très très très très très riche au niveau de la Ravel.
Donc tu profites de ça tout en allant assez rapide,
en allant assez vite,
parce que du coup, tu n'as pas toute cette partie API
à développer de doubles travail, etc.
Donc, par exemple, un développeur tout seul
peut développer beaucoup plus vite un système
avec du front en vue réacte
et un backend qui est hyper robuste avec la Ravel.
Ok.
Non, c'est pas mal.
Et donc production ready, tu me dis,
c'est pas nouveau, tout.
Tu veux peut-être partager ton écran,
parce que pour avoir plus d'infos, c'est quoi ?
C'est Inertia.js.
Là, on a un peu une vision globale
où on voit en fait un peu toutes les technologies
qui font la connexion entre le bas
qui est le front avec des exemples vraiment textuels et codés.
Donc tout de suite, on voit comment ça fonctionne.
T'as le site officiel, ouais.
T'as le site officiel qui vient d'être un petit peu revu au niveau design.
T'as la homepage qui explique vraiment les différents techno au niveau du bac.
Ça, je me rappelle plus, j'ai aimé ce que c'est, ce petit oiseau.
Là, tu as du rubis, tu as du Django, donc en piton, du Ravel.
Et après, devant, tu as réacte vu Svelte.
Donc les trois techno supportent actuellement.
Et on a un exemple, en fait, par exemple, pour la Ravel,
où on a le contrôleur, la Ravel, qui va aller chercher les utilisateurs
et après, qui va faire Inertia Render.
Et tu vois, en fait, les props, tu les mets ici, user au niveau du render.
Et ensuite, tes props, tu vas les récupérer dans ton composant vu, en front,
directement injecté dedans.
Et après, tu les affiches.
Donc c'est vraiment, tu vois, il n'y a pas de, c'est-à-dire que dans ton user.vu,
tu n'as pas besoin de faire une requête à JAX pour les chercher, les utilisateurs, etc.
C'est vraiment directement injecté.
Donc tu t'enlèves toute cette partie-là, qui finalement est plutôt pas très intéressante,
souvent, quand on développe un système, un projet.
Et on s'occupe vraiment que de la partie intéressante, voilà.
Le contrôleur.
C'est, ça fait vraiment la glue de manière très, très, très magique
et aussi bien pour un développeur back, qui va pouvoir envoyer les données hyper faciles.
Et pour le développeur front, il peut les récupérer via une probe, s'il y a toutes les infos.
Donc, et après, si c'est la même personne, c'est d'autant plus facile.
Mais même pour un travail en équipe, en fait, ça solutionne les deux parties.
En fait, on a la flexibilité des composants type React, Vuzevelt, on va dire,
les frameworks dits modernes.
Mais c'est vrai que souvent, en fait, on est obligés de faire des appels API.
Et là, on vient supprimer tout ce développement et cette lourdeur un peu d'API,
parce que tout est passé via des props.
Et tout le formatage, tout se fait automatiquement, nativement, on va dire.
Oui, complètement.
Et tu vois, alors, je fais vite fait, mais on a pas mal d'éléments qui sont pour améliorer les choses.
On peut charger les choses en différé, on peut...
Tu as un gestion de versioning, alors ça, c'est tout ce qui est parti vite,
JS qui gère tout ça, mais tout est déjà prêt, out of the box.
Tu as du pooling, le pooling, c'est quand tu peux faire un rafraîchissement automatique de la page.
Donc ça, tu as un component, enfin, un helper qui permet d'utiliser.
Infinite scrolling, ils ont sorti ça il y a pas longtemps aussi,
si tu veux faire une liste infinie.
Tu as des components pour ça, c'est hyper simple à mettre en place.
Il y a plein de choses qui te fascinent la vie.
Après, l'infinite scrolling, c'est juste une pagination avec...
On vient charger, on va dire, si j'en ai 20 sur la page, je viens charger les 20 suivants.
Quand je touche le bas de page, ça vient automatiquement recharger les 20 suivants.
Et ainsi de suite, c'est une pagination automatique.
Mais ça, ça, c'est du gérer automatiquement.
J'ai pas besoin de le coder.
Automatiquement, c'est-à-dire qu'en front, tu as un component pour le gérer.
Et après, tu as aussi un système pour le gérer.
Le front va automatiquement appeler le back,
et le back va répondre avec la pagination sans que tu aies beaucoup de code à faire.
C'est ça qui est vraiment génial.
Donc tu as plein de choses comme ça qui facilitent vraiment la vie au niveau du développement.
Et ensuite, il y a une doc.
Donc, tu vois, il y a le core concept.
On a pour qui c'est.
Donc, c'est pour les petites équipes, pour les développeurs indépendants, etc.
Donc, c'est ce qu'on a déjà dit.
Et comment ça marche ?
Alors, on va juste rapidement expliquer comment ça marche.
Inertia, en fait, c'est principalement un router au niveau du front.
Donc, c'est un système de routing.
Et il intercepte en fait, en fait, on a des links un peu comme on peut retrouver dans Next ou Next.
On a vraiment un système pour les liens, un component link.
Quand on va cliquer dessus, en fait, lui, en fait, il va intercepter la requête.
Il va envoyer une requête à Jax au lieu de recharger la page.
Et au niveau du back, tout simplement, il y a un middleware qui capte, en fait,
le fait que c'est une requête Inertia.
Et au lieu de renvoyer une page HTML, il va renvoyer un JSON.
En gros, ça fonctionne comme ça.
C'est une sorte de router intelligent qui vient créer un type un peu hybride.
Et ce qui fait que quand ça sort ou quand ça arrive,
c'est formaté d'une certaine manière pour que ça soit interprété.
Et donc, il y a toute une librairie de composantes dédiées et spécifiques à Inertia.
C'est ça ?
Oui, c'est ça.
Donc, voilà, le lifecycle, comme ils ont fait un petit diagramme.
La première visite sur ton application,
la Ravel va rendre le HTML complet avec les props injectés au niveau du HTML.
Et ensuite, l'application va se lancer, vue ou réacte,
et va récupérer les props et les injectés, etc.
Donc ça, c'est vraiment le premier chargement.
Et une fois que c'est chargé, dès que tu vas cliquer sur un lien
où tu as utilisé le fameux link, le component qui permet de faire des liens,
là, il va s'occuper de faire des requêtes à Jax, etc.
Et en fait, ce n'est pas assez basique, c'est assez simple.
En fait, c'est juste, voilà, c'est magique oui et non.
C'est juste simple, un système de routine qui récupère les requêtes
qui les fait à ta place, en fait.
La requête est surchargée, justement, là, on voit avec le X Inertia True.
C'est ça.
Et en fait, la requête est surchargée de cette information-là,
et donc, elle peut être interprétée côté BAC pour rendre toutes les infos.
Excellent.
C'est grâce à ce X Inertia, qui est dans le Header, en fait,
qui permet au Middleware, côté la Ravel, de dire,
ah, ça, c'est une requête Inertia.
Donc, je renvoie plutôt un G-Zone.
Donc, le G-Zone, il ressemble à ça.
C'est une sorte d'infos avec quel component je dois rendre,
les props à injecter, quel URL, etc.
Ça fonctionne un peu près comme ça.
Excellent.
Après, je vais parler plus loin, mais c'est déjà,
on comprend un peu près comment ça fonctionne, tu vois.
Donc, un Middleware côté BAC et un système de wikiapt les requêtes
pour faire des requêtes à JAX et remplacer.
Et là, je vois, il y a des composants qu'ils appellent basics,
les pages, les responses, les redirects.
Ça, c'est des composants que tu vas utiliser dans ton framework,
donc React V.
Mais c'est des composants qui sont codés pour chaque framework,
ou c'est une sorte de métal composants qui sont au-dessus.
Alors, ce n'est pas vraiment des composants,
c'est plutôt là le basique, là, ils expliquent chaque élément comment ça fonctionne,
les pages, comment elles fonctionnent, les réponses, les redirects, tout ça.
Ils expliquent un peu comment l'utiliser, tout ça.
Les links, oui, c'est un composant, qui est là.
Et oui, le code pour React, pour Vue et pour les autres frameworks.
Oui, spécifiquement, après, chaque fois, c'est toujours la même chose,
mais les formuleurs, c'est pareil.
On a un component qui est aussi Vue, React, C'est Asveld.
OK, par contre, c'est composants-là et c'est des composants non-designés,
si je comprends bien.
C'est des composants purement fonctionnels.
Et donc, c'est des composants fonctionnels.
Et après, à Libranu, en fait,
devenir les surchargés dans un composant de design
pour pouvoir mettre tous nos éléments graphiques, on va dire.
C'est totalement des composants fonctionnels.
Ce n'est pas du tout une librairie de composants,
comme on peut avoir, une Next UI ou autre.
Et vu que tu parles de Next UI,
aujourd'hui, il y a des chats de CN, il y a des choses comme ça,
et est-ce que tu peux utiliser tes composants de librairies qu'on connaît tous
et venir trouver un mix entre les deux
pour pouvoir profiter de la vitesse de déploiement
avec Inertia et la vitesse de Dev,
tout en profitant des bons composants un peu chiais des quoi.
Oui, tu peux totalement.
Dernièrement, actuellement, j'utilise Next UI.
Et en plus, Next UI, c'est top parce que c'est totalement compatible
avec... Alors, vue, évidemment, pas du React, mais on est plus sur du vue.
Par contre, c'est totalement compatible avec Inertia.
Ils ont fait le taf pour que tu puisses intégrer facilement
dans une application Inertia, donc ça, c'est top.
Et pour ceux qui connaissent Next UI, c'est vraiment simple à utiliser.
Il n'y a pas grand-chose à régler.
Et c'est Nuxt.
Oui, c'est pas comme les autres systèmes Shad CN
où tu dois un peu faire de la config, etc.
Là, il n'y a vraiment pas de config.
C'est du Tailwind, du composant vue, et c'est hyper simple à utiliser.
Pour ça, c'est top.
Et par contre, ils ont sorti, et donc on en avait déjà parlé
dans un épisode, la Ravel a sorti des Starter Kits
qui sont soit React, soit vue,
et ceux-là sont sur Shad CN.
OK.
Donc c'est totalement compatible.
En fait, de toute façon, au niveau du front,
tu fais exactement ce que tu fais habituellement
avec n'importe quel framework,
que ce soit vu ou React.
Tu travailles comme d'habitude, tu peux utiliser ce que tu veux.
Il n'y a pas de problème.
Inertia, c'est juste un paquet de gens plus que tu vas rajouter
pour gérer les liens, pour gérer les formes, etc.
Mais ça ne change pas du tout ta façon de développer.
Ça reste identique.
Tu ne changes pas tes habitudes, tout ça.
Il n'y a pas de truc spécifique.
Un petit peu quand même pour intégrer cette nouvelle techno,
mais tu es en train de me dire que la doc est bien faite,
que le lien de temps est significatif,
et que une fois que j'ai goûté à ça,
la fluidité et l'expérience de dev fait que c'est super facile.
Donc je vais continuer à l'utiliser pour faire court.
C'est vraiment top.
Franchement, c'est top.
Après, je ne dis pas que c'est le truc ultime,
et qu'on doit utiliser que ça.
Ça dépend des projets, pour un internet,
pour un admin ou tu te connectes, c'est génial.
Après, pour du front,
où tu vas avoir besoin d'un rendu SSR, etc.
Je le conseille peut-être un peu moins.
Si on est sur du Laravelle,
je conseillerais plutôt de faire du LiveWire,
ou autre,
ou un système HTML, ou classique, etc.
ou passer sur autre chose.
Je trouve que c'est hyper adapté
pour faire un backend de tout ça.
Vraiment top.
Une SPA, tout simplement, comme on dit.
Ça pour ça, c'est super, super adapté.
Après, ça dépend.
Mais franchement, c'est top.
Ok, ça marche.
Est-ce qu'on peut faire ?
Je peux vous faire voir un petit peu de code ?
Alors, j'ai fait un mini projet.
Donc, on ne va pas trop coder, mais je vais vous faire voir du code,
parce que ça reste un petit peu au niveau audio,
que ce soit encore écoutable.
Et surtout, concrètement,
c'est quoi ?
C'est deux packages.
Est-ce que tu pars de toute façon,
tu vas tout le temps partir de ton bac,
et tu vas venir implémenter le bac,
parce que tu vas implémenter le côté bac,
côté front, mais on est bien d'accord
si à ce que tu as dit au départ,
c'est toujours pour des projets, en fait,
dits monolithiques.
Ce n'est pas des micro-apps,
une app fronte et une app bac.
C'est vraiment pour des applis monolithiques,
pour faciliter la connexion entre le bac et le front,
avec du JS.
Mais c'est pour du monolithique uniquement.
C'est-à-dire que tu pars d'un projet la Ravel.
On va rester sur la Ravel,
parce que c'est vraiment sur ce que j'ai travaillé.
Franchement, le fonctionnement est vraiment identique
suivant le framework.
Le concept est le même, tout est pareil.
Après, je suis sur du la Ravel.
On va rester sur de la Ravel.
Tu pars sur un projet la Ravel,
avec la structure habituelle,
comme on voit sur le code.
C'est vraiment la structure habituelle
qu'on retrouve quand on lance un projet la Ravel.
Et derrière, ce qu'on va rajouter,
au niveau Composeur,
c'est le gestionnaire de package de PHP.
On va tout simplement rajouter Inertia la Ravel.
C'est la seule chose qu'on va rajouter,
au niveau du bac.
Ensuite, on va implémenter un mille heures.
La doc n'est pas super complète.
Il manque des trucs.
On va ajouter un package sur Composeur,
Inertia Js, Inertia la Ravel.
J'en parlerai aussi.
Il y a WifiDir,
qui est là.
Un package,
je vais vous expliquer le fonctionnement derrière.
Ça permet de faire le pont entre le bac et le front.




On va pouvoir récupérer les types côté front et bac.
Si on a typeé,
parce que la nouvelle version de PHP,
si j'ai bien suivi les épisodes de Wslash,
la dernière version de PHP,
il y a du typeage.
Et là, tu es en train de dire qu'on peut exporter
les typesages de mon PHP
vers du TS côté JS Front.
On va dire ?
La difficulté, quand tu fais un bac en PHP
et un front en Java-Scrub,
c'est les typesages entre le bac et le front.
C'est beaucoup plus simple quand tu fais du JS
en bac pour avoir les typesages.
Souvent, ça génère tout ça.
Il y a pas mal de packages
qui ont été créées pour faire ça,
indépendants, etc.
Et là, on a WifiDir,
on avait déjà parlé dans les épisodes,
qui actuellement, sur la version actuelle,
génèrent les typesages pour les routes.
Donc c'est pratique.
Je voudrais voir,
mais pour les routes, c'est facile.
On sait si on doit mettre un argument,
et la nouvelle version
qui va sortir,
qui est en beta de WifiDir,
va aussi générer
les types des routes,
pas des routes des objets,
ce qui est injecté
dans les props.
Au niveau des props.
Là, la prochaine version,
on va gérer tout le typeage des props,
des routes,
tout,
vraiment tout.
C'est plutôt pas mal, c'est en beta,
c'est en test.
C'est pour ça que j'ai mis DevNext,
la version beta que j'ai installée,
pour vous faire voir.
Du coup, on a vraiment un système
qui va générer le typeage du back
au front,
et le rendre disponible pour ton application.
C'est top top.
On n'a pas grand chose.
Au niveau du back, on a le package inertial,
le package WifiDir, c'est tout ce que j'ai rajouté.
Ensuite,
au niveau, comme je disais,
c'est un middleware
qui gère
les requêtes inertiaires.
Dans la Ravel,
on va créer un middleware
qui est ici,
assez simple,
et on va pouvoir sortir des éléments.
C'est le seul middleware,
tu vas faire un seul middleware
pour interpréter
inertiaires.
Toutes les requêtes inertiaires
vont passer là-dedans,
et ça va juste décoder
les infos.
C'est ça.
Il est là.
Il est ici.
On a le
middleware inertiaire request,
donc il y a un middleware qu'on va enregistrer ici,
qui va
capter toutes les requêtes,
et dire que c'est inertiaire,
et ensuite injecter ce qu'il faut.
Ce middleware,
ici, on a un système
qui s'appelle share,
une fonction où on va pouvoir
partager des éléments entre les compagnons.
Au lieu de le mettre au niveau de la route,
on va pouvoir dire que
quelqu'un est authentifié,
l'utilisateur,
on va mettre les infos de l'utilisateur ici,
ça sera partagé dans tous les compagnons,
au lieu de le mettre
à chaque fois dans la props,
du contrôleur.
On peut partager
des éléments, des props,
automatiquement, et une fois que c'est mis,
ça se partage tout le temps dans toutes les pages.
Toutes les infos,
si tu les as partagés
à un moment,
ces infos sont partagés
sur les nouveaux composants,
ou sur les nouvelles requêtes,
ils vont aussi
surcharger de toutes ces informations.
C'est hyper pratique,
surtout pour l'authentification
ou des détails que tu utilises un peu partout,
sur le niveau de qui,
tout le reste.
Ça c'est pas mal,
donc ça c'est sur le bac,
juste un middle bear,
c'est hyper simple à mettre en place.
Et après, au niveau du front,
si je vais dans mon
package.json,
j'ai juste
Inertia v3,
ici un package.
Donc, adapté, parce que là, je l'ai fait en vue,
donc c'est v3, sinon ça aurait été réacte.
Mais on a juste ce package à rajouter,
évidemment vu,
Next UI aussi parce que j'utilise Next UI,
donc tu vois, j'ai 3 dépendances,
et c'est tout ce que j'ai en fait.
Et après, j'ai un package WFinder, qu'on va rajouter
sur VIT pour tout ce qui est génération type,
tout ça. Mais en d'autres fois, c'est assez
basique, il n'y a pas grand chose
au niveau du front, il y a juste un package,
voilà, v3.
Et après, dans
mes pages,
il me suffit
d'utiliser les composants
spécifiques à Inertia
pour pouvoir profiter
de ça, ou je dois déclarer
quelque chose
en plus dans mon côté front.
Non ?
Alors non, du tout, tu vois,
je vais te faire voir. Alors au niveau du contrôleur
du PHP,
donc je crée des routes, alors pour
je vais aller vite expliquer rapidement
pour les gens qui ne connaissent pas la ravelle.
Là, on va déclarer les routes ici.
Donc, tu vois,
le chemin, quel contrôleur
et quelle fonction.
Voilà. Donc là, j'ai toutes mes routes.
Donc indexcontroller, c'est celui-là.
Donc l'index, c'est là, c'est la première page.
Et ici, en fait,
pour dire,
je vais rendre un composant, enfin,
une page, ici, c'est Inertia Render.
La page, c'est index.v.
Et ensuite, les props, c'est ça.
Tout simplement.
Donc là, en fait, on est dans le contrôleur
et c'est là où tu vas injecter
en fait toutes tes
ressources et toutes tes dépendances.
Et au lieu de faire ton
render, on va dire, en JSON
ou en HTML,
là, tu vas lui spécifier
en fait que c'est un render
Inertia et tu lui mets
toutes tes props. Et potentiellement,
tu peux lui donner autant de props que tu veux.
Tu mets ce que tu veux.
Ouais, tu mets ce que tu veux et tout est transformé
en JSON, en object-json.
Là, habituellement, sur un contrôleur la Ravel,
tu as un render
avec un nom
de vue Blade.
Tu sais, le
Blade, c'est le moteur de template
qui est par défaut dans la Ravel.
Donc on va rendre un template
Blade et voilà, ça va rendre du HTML.
Et là, donc avec ce Inertia Render,
on va plutôt rendre une page
vue. Donc lui au niveau du front,
ce que j'ai créé,
ce qu'on doit créer,
c'est dans app.ts, donc le point d'entrée
de l'application, comme on peut l'avoir dans vue,
généralement dans une application
vue, tu as un app.ts,
tu as un create app
qui est ici d'ailleurs,
et là tu vas générer ta vue,
enfin ton application vue,
et elle va se construire grâce avec le create app.
Donc là, c'est pareil, dans le app.ts
on a juste un create Inertia app
avec un resolver, et
après le setup, c'est
create app, donc on va créer l'application vue.
Donc ça reste vraiment très proche
de ce qu'on fait habituellement.
On crée une application vue, rien de plus
que ça. Et donc
là, ce que j'avais fait voir dans le contrôleur,
dans l'index,
j'ai affiché la page, donc index,
tout simplement, il va la chercher
là, dans page.
Donc là je suis dans le gs, donc c'est l'application
en front, dans page.s, on a
index.vue, voilà, la page est là.
Donc automatiquement, il va injecter
les postes ici.
Ok. Et
d'où l'importance
en fait de bien respecter
les conventions de nommage,
en fait, si tu respectes les
bonnes conventions de nommage, tu n'as pas besoin
de définir le chemin, il est
automatiquement interprété, parce que
tu as bien respecté les bons noms,
et ça fait tout seul, quoi.
Sous couvert que tu as bien mis les bons
noms à chaque fois, quoi. Donc
c'est vraiment sur une approche
convention over configuration,
quoi. Si tu respectes les conventions, ça marche tout seul.
Ouais. Ok. C'est ça.
Là, je vais lancer
mon compositeur, je sais pas pourquoi.
Et par contre là, je vois dans
Define Props, il y a
Inertia page post,
ça veut dire que dans mon composant
front, je dois quand même
lui spécifier que
cette propse en fait
elle est
de type
Inertia, quoi. C'est la page
de Inertia.
Parce que sur la définition
de propse, parfois tu peux
rentrer beaucoup
d'informations, tu peux mettre
des validations, des choses comme ça.
Là, en fait, je vois que c'est
d'abord Inertia, puis Page, puis
Post. Donc
en fait, on lui spécifie
bien le chemin
qu'on veut
à l'époque.
Ouais, tu vas assez vite parce que
déjà c'est au Wifinder, mais
effectivement, c'est la nouveauté
de... Alors là, il est en...
Je sais pas pourquoi ça veut pas se lancer.
Parce que ça marche sur... Voilà, c'est bon.
En fait, sur
la nouvelle version de Wifinder, tu as
justement accès directement à
des Inertia. La page
Post, en fait, c'est...
Et donc là, ça me donne normalement...
Je sais pas pourquoi ça me déconne,
mais normalement, tu as directement accès
à la valeur de Post, en fait. Qu'est-ce
que c'est? Ok. Et ça va directement
prendre dans le modèle, en fait, parce que
ici
tu as un modèle Post, par exemple, où tu vois
on a un title, un content. Et ça va
directement générer un type
de Post et avec un title
string. Ok, parce que c'est
Wifinder et Wifinder, c'est
le typeage
des objets, on va dire.
Et donc, t'es obligé, en fait,
de lui passer le Inertia
page.
Parce que, en fait,
tu viens, en fait, te typeer
ta props avec ce fameux
Wifinder,
qui est le typeage
sur la ravelle
pour faire des
injections. C'est ça? Sinon, en fait,
ça serait un truc un peu plus classique
non
typeé. Ta props
ne serait pas typeé, c'est ça?
Oui, en fait, si tu ne dis pas
Wifinder, c'est toi qui es obligé de typeer
à chaque fois de créer des types type-trips
pour dire le Post, le title, le content, etc.
etc. Ce que j'ai fait
sur mon projet d'Internet
qui est sur lequel je travaille en ce moment,
parce que Wifinder est en version
beta avec le nouveau système de typeage, mais
moi, sur mon projet actuel, il n'y a pas
d'version, il n'y a que les routes qui sont typeés.
Donc,
tu n'es pas assez chers de
faire du pétain
? Non, mais ça vient de sortir.
Ça vient de sortir
et je t'avoue que j'ai un peu
un peu d'hématisme, dommage.
J'ai fait tout le code.
Mais d'un autre côté, je me pose la question
sur la problématique,
c'est que là, par exemple,
si tu reçois
les props qui arrivent
dans la page actuelle,
mais moi, derrière, si tu veux, on a des components
où tu vas aussi passer des props,
et je n'ai pas encore vu comment je pouvais
décomposer ces props,
parce que là,
les déconstruire, tu veux dire ?
En fait, moi, les posts, par exemple,
généralement, tu vas faire un composant
de liste post, donc il faut leur passer
ces posts à la liste. Alors, je n'ai pas encore vu
si je réutilise ça.
Franchement, c'est vraiment en version beta,
c'est tout nouveau.
Donc, je vais voir si je l'implémente maintenant
ou si j'attends un peu que ça sort de la version beta.
Normalement, c'est plutôt stable,
mais bon, à voir.
Mais en tout cas, c'est pratique, tu vois, parce qu'on peut utiliser
directement les types, sans nous les écrire,
c'est généré directement
à chaque fois. Ça récupère
le type-age de ton objet
qui est suité en tant que ton modèle.
Ouais, c'est instantané. C'est-à-dire que
là, si je change au niveau du
PHP, ça va
automatiquement régénérer les types pour le front.
Donc c'est hyper rapide.
Donc, tu as un watch qui tourne.
Ouais.
Nice.
Trop bien.
Voilà, c'est automatiquement reloadé.
Donc, j'ai lancé
le projet.
C'est un truc tout simple.
En fait, c'est juste
une liste de postes.
Je peux créer un poste.
Je peux modifier un poste.
Et on va regarder ensemble
comment ça fonctionne.
C'est surtout pour pouvoir
faire voir au niveau de la liste.
La liste est ici.
Donc, c'est juste que je récupère les postes.
Donc, les fameux postes que je fais
la requête. Donc, je rappelle, c'est dans
une database SQLite.
Par défaut, quand tu crées un projet la Ravel,
tu as une base SQLite qui s'installe.
Et après, tu peux passer
sur d'autres bases de données.
Mais voilà, ça suffit. Donc, je vais faire
une requête. Donc, c'est ça l'avantage aussi.
C'est qu'au niveau du bac, tu utilises
Eloquent, qui permet
c'est l'ORM de la Ravel,
qui permet de faire des requêtes à la base
de données. Donc, l'avantage, c'est ça, c'est
qu'au niveau du bac, on peut utiliser
l'ORM, etc. Tout ce qui est déjà disponible
pour faire des requêtes.
Tout ça, on n'a pas besoin de
faire autre chose. Donc, c'est pratique,
puisque je fais ma requête. J'injecte les postes
et ils sont disponibles directement ici.
Donc, c'est ultra simple à mettre en place.
Donc, là, j'ai ma liste.
Je la fiche tout simplement.
Et au niveau des formuleurs,
ils sont ici.
Donc, là, j'utilise
NUX2UI. Donc, c'est pour ça, tu reconnais
les UFormField, UInput
qui sont là.
Et, en fait, le formulaire,
c'est le composant formulaire de Inertia
qui permet de gérer donc les erreurs
ou processings.
Donc, c'est juste englober
en fait mes champs dans le composant
formes. Et à partir de là,
c'est géré automatiquement.
Excellent.
Et par contre,
ta validation va se faire
côté-back, tu disais.
Exactement. Ok.
Ce qui veut dire que
si Jean-Michel il n'a pas mis un bon
email, tu vas quand même taper
ton serveur pour voir que c'est pas un bon
email, quoi.
Après, voilà, c'est le
parti pris de Inertia.
C'est l'avantage. Après,
on a tous des
politiques un peu différentes,
tu vois, sur des services
qui se font énormément
qui sont
en énorme demande.
Il y a aussi une approche quand
disant, en fait, il faut faire une validation
côté fronte pour valider
déjà que c'est un bon email. Ça sert
à rien d'envoyer la requête au serveur
parce que, de toute façon, son email
il est pourri. Donc après, voilà, il y a
une approche où tu peux faire
une prévalidation
en front.
Mais du coup, à chaque fois, ça te fait 2 validations.
Tu dois valider en front. Exactement.
Et ensuite, ton API va encore valider. Donc ça te fait
double travail, en fait. Et là,
tu le fais qu'une fois. Je le fais qu'une fois
parce que, par exemple,
si je vais dans mon contrôleur,
donc le contrôleur
il est là, le store, la fonction
store, en fait, c'est celle qui va, quand je crée
un poste, c'est elle qui
va gérer. Donc au niveau de la ravelle, on a
un système qui est de request.
Donc tu vois, il y a du type page, ici. On a
une injection de dépendance. Donc automatiquement,
request est disponible et déjà
instantiée.
Je valide.
Donc là, c'est validate. J'ai un title,
un content qui sont obligatoires.
Et donc, je te fais voir
si je clique sur crée. Donc, alors,
tu vois au niveau de mon front, la create
c'est mon formulaire
de front. Je n'ai pas de système
de validation, en fait. On a des slots qui sont ici
et processing. Donc processing quand on est
en train d'être envoyé et tout ça.
Error, c'est s'il y a des erreurs qui sont envoyées.
Tu vois, c'est hyper simple. J'ai juste des champs.
Et bien quand je clique, je clique crée
automatiquement, voilà. Oui, par contre
moi, ce que je veux savoir, c'est est-ce que
t'as tapé ton serveur ou pas ?
Oui, ok.
C'est le serveur qui renvoie les erreurs,
en fait. C'est pas du tout le front qui
renvoie les erreurs. C'est ça qui est
qui est, tu vois,
en fait, c'est validé uniquement côté back
et tu fais qu'une fois le travail. Et donc
le front affiche ses erreurs,
c'est pas passé, hop, ça revient.
Ok. Et si par exemple
j'envoie, j'enlève ça,
je fais
nul et pas nul.
Tu vois, j'ai changé en back.
Ouais, ouais. En fait, le title
peut être nul, mais pas le texte.
Et bien automatiquement, tu vois, et c'est juste là,
c'est juste au niveau du back. Donc, je ne fais qu'une
seule fois la validation. T'as pas besoin de faire
une validation contre les front et contre les back, au niveau
API. Tu le fais juste côté back
et le front affiche ses erreurs.
Et c'est vraiment ça qui est hyper puissant, en fait.
Rien qu'au niveau du formulaire,
c'est juste incroyable tant que tu peux gagner.
Parce qu'on sait très bien, les formuleurs,
c'est une des choses les moins intéressantes
à faire. Oui, c'est le moment.
Et la validation des formuleurs, encore plus.
Donc, si tu peux la faire qu'une seule fois
et côté back, c'est parfait.
Parce qu'en plus, tu vois, la côté back
il va me valider les trucs.
Si c'est ok,
il me les met dans validation.
Et ensuite, je crie mon poste tout simplement.
J'ai pas besoin de faire avec les valeurs
qui ont déjà passé.
Voilà, avec les valeurs qui sont passées.
Donc, tu vois, ma fonction,
elle est
quelques lignes, en fait, pour
valider et sauver un poste.
Parce que si j'avais pas ça,
j'aurais dû faire le formulaire
qui valide les data.
Et puis, je vais faire ça.
La requête qui va envoyer les data.
Éventuellement, gérer aussi les retours
si la pays me dit, bah non, ça passe pas.
Si tu vois, si il y a un truc qui
n'est pas identique.
Et ensuite, au niveau de la pays, il aurait fallu enregistrer.
Ok, c'est bon.
Tu retournes pour dire, bah c'est validé,
c'est enregistré. Tu vois, je te dis pas le travail
que tu as à faire par rapport à juste ça,
en fait, faire un bac qui dit ok, c'est validé.
Et après, je fais une redirection.
Donc, en fait, qu'est-ce qui se passe
si je fais ça ?
Je crée.
Et sur la tâche, tu as créé ton poste
facilement.
Ok, top.
Et c'est sûr que
toute cette interprétation
de validation
peut être super compliquée
et pas très agréable à faire.
Et là, en fait, tout est centralisé.
Top.
Tout est centralisé, tout est clean.
Et surtout, tu as tout un
système d'alper.
On est sur de la ravelle, mais que ça soit
du Django n'importe ou du Rubin Race, c'est pareil.
Tu as des fonctions comme ça qui te permettent
vraiment de valider des choses,
de créer des postes.
C'est hyper simple. Et pareil,
au niveau de l'update,
au niveau de l'update,
par exemple, ici
sur la ravelle, on a un binding
au niveau de la route. C'est-à-dire que quand
tu arrives, quand je clique sur
Éditer, ici,
donc là, j'arrive sur cette fonction
au niveau du back, j'ai la request
et j'ai aussi déjà le post
qui est déjà créé. Avec l'ID,
en fait, la ravelle va chercher le poste
et l'injecter ici.
Et donc moi, je n'ai même pas besoin de faire de requêtes
au niveau de la fonction
pour aller chercher le poste, il est
déjà disponible, il est déjà identifique.
Voilà, c'est bindé,
il arrive directement dedans, je modifie
et puis...
En fait, c'est tellement simple
que...
Voilà.
C'est perturbant tout ça.
Est-ce que quand tu viens
ou tu tapes tout à la main,
en fait, il y a quoi ? Il y a un côté
magique, un côté perturbant
ou il y a un côté énorme,
c'est du cheat, c'est
limite, c'est cheaté,
tellement que c'est facile
ou au final,
tu prends vite goût et après, ça devient
standard ?
Non, tu prends vite goût et puis tu peux
implémenter
plus rapidement des choses.
Donc ça, c'est...
Petit truc, comme je te disais
de tout à l'heure,
au niveau de Wifinder,
ce que je disais, c'est qu'au niveau du route,
on a du typeage,
exactement là,
tu as le store,
en fait, quand les routes,
il va les créer
de mes routes,
et là, il sait en fait,
voilà, j'ai
la fonction store, tu vois,
j'ai la fonction edit, tout ça, tout ça, c'est disponible directement
et je la récupère ici
et le store,
donc là, j'ai ça, mais dedans,
tu as URL ou méthode,
donc tu peux afficher la URL
ou la méthode, alors dans les formuleurs,
on met directement la fonction et lui, c'est
déjà au niveau de l'action, la méthode et de
l'URL, mais on peut l'utiliser
aussi dans mon component de navigation,
tu vois, au niveau de la navigation,
au lieu de mettre un truc en dur,
au niveau de l'URL,
je mets index que j'ai été chercher,
point URL, c'est-à-dire que
si, une fois que j'ai ça en place,
si jamais au niveau du back,
j'ai envie de changer la route,
si je vais là et que je change la route,
je veux plus que ça s'appelle create, mais je new,
par exemple,
automatiquement, le front ça va changer aussi.
Je peux pas de repasser sur toute mon application
pour changer les URL.
Ok, donc en fait, c'est comme si
tu avais créé une sorte de raccourci
ou de proxy,
on va dire, on va dire
fonctionnel, ce qui fait que même
si tu changes le nom,
au final, ça va pas
ça va tout se faire
de manière dynamique, tu ne seras pas obligé
de passer sur ton application
pour faire toutes tes modifications,
donc tu as été un sorte de proxy
intelligent pour
ton routing dynamique, on va dire.
Ouais, c'est top.

donc voilà, tu vois les formulaires, la puissance
du truc et tout ça,
tu vois, c'est une application
vue comme on peut en faire tous les jours,
la seule différence, c'est qu'on va utiliser
des éléments inertia, en plus, dans
cette application. C'est la seule différence.
Évidemment, on a des composantes
qu'on peut retrouver sur tous les frameworks
Heads, par exemple,
pour injecter un title
dans le Heads de la page,
tu vois, là je viens de le mettre.
Donc normalement, maintenant
on a list de postes,
donc c'est des choses, voilà
c'est tous des helpers qui nous permettent
vraiment de, je vais s'en remarquer
aussi, je n'ai pas de layout
qui est déclaré, là,
dans mon composant,
dans ma page, je l'ai déclaré
ici, j'ai mis, alors là
j'ai mis un, voilà,
j'ai mis un layout
il est là
par défaut, c'est le
layout standard
pour pouvoir une sorte de wrapper
le défaus, c'est celui-là,
voilà, du coup, fortement,
c'est de suite injecté.
Petit changement aussi, alors je parais
de Wayfinder qui est en version beta
autre chose qui est disponible de suite,
c'est ça. Alors habituellement
en fait, si je
montre le,
peut-être je redémarre.
habituellement en fait,
actuellement
les data
de base
quand tu charges la première fois la page
voilà, c'est ça
je ne sais pas, je vais grossir un peu
actuellement en fait, c'est
injecté dans un attribut data page
d'accord,
donc c'est des données
surchargées
oui en fait, toutes les, voilà
le premier chargement de l'application
les props
pour lancer l'application, ils sont
injectés dans un attribut data page
ça c'est actuellement
comment ça fonctionne
ils sont en train de changer ça
il y a un gars, d'ailleurs c'est un, toi c'est un
contributeur qui a lancé ça et qui l'a fait
ils sont en train de changer ça
c'est-à-dire qu'ils sont en train de changer
donc via
cette valeur dans le point
enve, et via, tu vois on est dans
le futur, donc c'est vraiment un truc qui est en train
d'être mis en place mais qui est déjà à peu près
stable donc c'est une feature flag
en fait c'est une fonctionnalité qui est déjà
opérationnelle
qui n'est accessible que sur
déclaration, configuration
d'un feature flag avec le
use script
élément foie inertia
et ça, qu'est-ce que ça va changer
ça change ça, hop
la différence c'est que maintenant
tu vois c'est dans un
script
en fait c'est plus dans le
là on a le app
où on avait l'attribut, maintenant c'est plus
dans le livre, c'est dans un script
application json
où ils ont mis, donc tu vois c'est un peu, on est
comme dans un next ou un next
donc c'est plus propre, en fait ça vient
vraiment séparer
le rendu du DOM
avec tes injections
de données, là en fait en
line de script avec toutes les données
qui sont de type application json
et il n'y a pas en fait
cette injection, par contre là on est
bien d'accord que dans ton exemple
vu qu'on a le DOM
qui est vide
et une balise de script
où il y a toutes les données, il y a toutes les props
là on n'est pas du tout en SSR
on est bien d'accord
non, le SSR a pas de rendu serveur
parce que l'application
app
ou en tout cas l'injection
de données se fait à posteriori
via du js, donc ça veut dire que le DOM
est vide, donc notre
ami Google
ou chat gpt il aime pas du tout
parce qu'il a rien à voir
non, là on est vraiment en mode SPA
donc truc classique, un div
totalement vide et l'application est
générée dedans, donc
l'avantage de passer par
un application de JSON au niveau des data
c'est que le parsign
en fait de l'application
alors du coup là c'est un peu
tout vide, mais si jamais tu fais du SSR
le fait qu'il y ait un attribut
avec des data qui soient
parfois conséquentes si tu mets beaucoup de data
ça a ralenti un peu le parsign
de tout le node
donc le fait de le mettre en script
c'est beaucoup plus efficace
et surtout si tu refais
une requête
si tu fais
une modification
tu ne vas modifier que la partie
que tu as bougé
je pense que tu as une notion
de composants qui va pouvoir
appeler uniquement
les infos qu'il a besoin et que tu n'as pas besoin
de recharger toute la page, je suppose
je ne sais pas, c'est une question
les proches qui sont injectées
au premier chargement après
elles changent pas en fait
après les requêtes vont faire en Ajax
et les props qui vont être chargés
seront via la requête
donc ce qu'il y a dans la page, dans le HTML
de base ne change pas
c'est vraiment la mise à jour des props
en fonction de la navigation
c'est vraiment récupéré par la requête
d'accord, en général
dernière chose que je voulais faire voir
c'était
par exemple
tu veux
des fois on a bougé de mettre un store
pour gérer un state
tu veux
faire un filtre ou n'importe quoi
donc le filtre, qu'est-ce qui active
tu veux mettre un store en place avec Pinias
sur vue par exemple
il y a quelque chose qui est vachement intéressant
là j'ai mis en place un filtre
un système de filtre
donc ici une recherche
donc le filtreur
il est ici, il est
juste un champ tout simple
avec un modèle
avec une référence et un value
comme je disais c'est un router
inertial donc on a une fonction
router évidemment qu'on peut appeler
pour faire des actions, visiter, changer de page
etc. ou recharger la page
et ça nous permet de recharger
aussi les props
l'avantage, c'est que là par exemple
comment fonctionne mon filtre, quand je vais
taper des mots
le ref, forcément c'est lui qui récupère tout
et je watch cette référence
pour dire si ça change, update
la query
dans cette index
je peux mettre une query
des paramètres
qui seront search
pour le coup
ça va s'injecter automatiquement
et ça va faire un rechargement
de postes, donc là les props postes
vont être reloadés
automatiquement et ça va
afficher le résultat
par contre est-ce que tu recharges toute ta page
ou c'est uniquement la props qui est rechargée
c'est là toute la puissance
donc si je fais juste ça
ça m'a changé
sans rechargement
et donc la valeur est là
et donc en quelque sorte le state
est géré avec l'URL
et c'est vraiment pratique
pour l'internet
j'ai pas mal de systèmes de calendrier
avec des dates etc. donc il va passer
d'une semaine à une autre tout ça
et donc toutes les valeurs se mettent dans l'URL
et l'avantage évidemment
c'est que si je recharge
tu gardes
donc en fait
toutes tes filtres
toutes tes infos de recherche
ou tes filtres sont passées
dans les query paramètres
de ton URL
donc elle est partageable
donc elle est rechargeable
donc elle est
hyper intéressante
en clair ça vient gérer dynamiquement
en fait tout tes
query paramètres de ton URL
voilà tu as un state au niveau de l'URL
t'as plus besoin d'avoir
comme je te dis l'internet là j'ai aucun store
et pourtant il y a plein de trucs de recherche
tout ça
mais tout passe par l'URL
donc le state est plutôt géré par l'URL
et donc tu t'as pas besoin de store
et tu peux recharger les pages etc.
tu perds pas ton moment ta requête
donc c'est vraiment pratique
et donc tu peux recharger
donc des props comme ça la volée etc.
c'est assez fluide
et assez facile à mettre en place
et le côté magique
pour l'avoir
fait un peu
alors déjà à la main
mais c'était pas fiable du tout
c'était vraiment la merde, c'était très compliqué
et après je suis passé par une librairie
justement en pure gs pour
faire ça
et c'est vachement plus intéressant
mais là il n'y a pas besoin de librairie
externe, c'est nativement en fait
c'est déjà pris en compte
et ça c'est
très très très puissant
parce qu'une fois de plus
c'est de la configuration
correcte
qu'on s'évite en respectant
toutes les conventions
donc c'est très bien pensé
c'est très très fonctionnel
et rapidement
enfin assez facilement
et rapidement
déployable
parce que cette fonctionnalité là
tu veux la connaitre toi même
ouais c'est hyper simple
en gros
ça te simplifie vraiment le code
avec toutes ces bonnes pratiques
ça te simplifie énormément le code front
et après au niveau back
si tu maîtrises ta techno
ça reste ce que tu connais
c'est propre
tu as des conventions
quand on est sur la ravelle
tu en as aussi sur vue évidemment
on a à peu près tout vu
mais après il y a plein de choses
donc on peut faire vite fait le tour
mais tu vois
ce qu'on avait dit
le partage pour toutes les componentes
là ils ont rajouté les flash data
c'est pour afficher une pop up
tu vois si jamais tu en rejutes
oui user, créé etc
genre des modales
c'est quoi ? c'est des modales
ou c'est plus l'équivalent un peu
de toast
c'est des toasts
tu vois au niveau du back
maintenant tu as un truc
tu as un interface flash
et après au niveau du front
tu fais ce que tu veux
après il y a toutes les bonnes pratiques
tu peux recharger les props
ce qu'on avait dit
tu as des props différents
qui seront chargés après le premier chargement
il y a plein de choses
le prefetching
qui peut être géré aussi
au niveau des liens
tu peux mettre des prefetch
des components qui seront chargés
uniquement quand c'est visible
l'infinite scroll, il y a plein de choses
qui sont déjà disponibles des helper
c'est assez riche
et ça fait que
au fil des versions
même des mineurs
ils rajoutent des petits components
donc ça m'éloigne très rapidement
top
top top
excellent
si
si moi je veux m'y mettre
j'ai envie
de tester ça
quelle serait pour toi
la meilleure manière de faire
c'est de tester
est-ce qu'il y a
la doc se suffit elle-même
ou il y a
on va dire des sites
un peu j'aime pas trop
tuto tu vois
une sorte d'unboarding pour venir découvrir
cette technologie c'est quoi le mieux
le mieux c'est de déjà
utiliser la technique
avec laquelle tu es à l'aise
je me rappel plus
si t'es plutôt
j'vais le trouver
je vais le trouver
tu fais
mvc
tu as raison mvc
mvc
j'y est
tu es quasiment sûr de le trouver
c'est la honte
adonis
c'est la honte
donc adonis est totalement
compatible avec inertia
donc évidemment si t'es plutôt à l'aise
en js
bah par sur adonis
qui est totalement compatible avec inertia
et je sais pas si ils en parlent
sur la doc
évidemment l'avantage
c'est de
c'est la gestion d'étipage
du coup c'est du js
enfin c'est même du ts
et front en ts
donc t'as la génération d'étipage qui est plus simple
à transférer entre les deux
par contre derrière le fonctionnement c'est exactement
le même qu'avec la ravelle
avec un render etc c'est vraiment tout
ok donc toi en fait
tu dis bien
tu pars de ta techno par exemple
j'ai du sainfo ou du la ravelle
j'ai l'habitude de faire ça
je veux tester
j'ai trifouillé un peu du vu
ou du réact
j'aime bien
vas-y je vais essayer de simplifier
la vie
je change pas ma techno back
mais je mets inertia
et si je suis la doc
de inertia
je peux m'en sortir
là je l'ai j'ai trouvé la page
d'inertia sur adonis
on est vraiment sur la même chose
tu vois t'as un inertia render
on est vraiment sur le même concept
tout fonctionne pareil en fonction
du framework c'est toujours la même chose
les mêmes concepts
voilà c'était à l'ège avec js ou ts
bah pars sur du adonis
c'est fait d'inertia
si t'es à l'aise en php et en js
la ravelle c'est une bonne solution
et toi
tu trouves que la learning curve
voilà la courbe d'apprentissage
pour éviter de faire des anglicismes
trop souvent
la courbe d'apprentissage
elle est dure
ou au final elle est plutôt facile
et on peut facilement
plonger
dans cette livrairie
ou il y a comme une barrière
à l'entrée
c'est hyper simple
si t'es à l'aise avec ton framework
que t'as habitué à la fronte
et le framework back
c'est tellement logique
et comme je t'ai dit ça change pas vraiment de toute habitude
c'est euh
la prise en main est très rapide
très très rapide
ok et est-ce qu'on pourrait donner
enfin est-ce que toi
tu pourrais donner des
des éléments pour inciter par exemple
un développeur ou un chef de
projet de passer là dessus
quels seraient les 3 arguments
que tu mettrais en avant
pour faciliter
en fait le job des équipes de dev
pour aller voir le project manager
le dire non mais il faudrait
ou le lead dev en disant
mec on se fait chier là
on pourrait faire ça, ça serait tellement mieux
pour toi
les 3 points clés à retenir
de inertia ça serait quoi
c'est simple
simplicité et du coup
t'as la maintenance derrière qui est plus facile
et puis
juste bon sens quoi
c'est juste du bon sens de simplifier les choses
j'avoue que j'ai eu
j'ai eu
des projets sur lesquels je n'ai pas travaillé
mais j'ai pu voir en fait le fonctionnement
des devs sur des projets
d'année dernière qui étaient le back
en symphonie, le front en React
avec du chat de CN
tout ça la complexité
et du coup le
temps pour mettre chaque feature
en place
très complexe en fait et là tu te retrouves
avec quelque chose qui est hyper simple j'ai envie de dire mais si
tu avais utilisé inertia
mais votre app vouloirait y sortir
en 2 mois au lieu de 6 mois
et surtout derrière la maintenance
c'est vachement facilité
parce que tu enlèves toute une partie
requête à jacks, balidation, API etc
donc
ok
top Patrick
écoute maintenant
comme d'habitude il y a plus cas parce qu'on peut
écouter parler de inertia on peut
regarder des tutos pendant
des heures et des heures mais
la seule vérité c'est
codé, tester
et je pense que là vous avez un
plutôt un ordre
un peu 360
d'inertia de tous les avantages
que ça peut avoir
donc y a plus cas merci Patrick
merci
merci
écoute on remercie tous ceux qui sont restés
jusqu'au bout de l'épisode comme d'habitude un petit pouce
un petit commentaire ça fait toujours extrêmement plaisir
et on vous dit à bientôt
pour la suite des épisodes
ciao ciao