Ce serait super de créer maintenant un tutoriel vidéo sur la documentation expliquer page par page en vidéo et faire des projets de site dynamique, de site e-commerce dessus.
Salut Loïc ! Merci pour la vidéo, mais ça fait un moment qu'on attend la suite pour Rust j'ai hâte de découvrir les nouvelles notions pourquoi pas des petits projets....
Une chose est de faire découvrir une nouvelle techno, mais c'est une autre chose quand tu essaies de boycotter l'autre. Pour un débutant en React c'est facile de gober cette comparaison, mais pour quelqu'un qui a de l'expérience en React, on voit clairement que tu es loin de comprendre et penser React.
0:24 Premier problème, aucun framework dans ta liste. As-tu essayé Angular? 0:40 Oui, c'est le principe. Si tu veux les partager, stocke les dans un service. 2:09 Effectivement, un même langage des deux coté simplifie les choses, et à choisir, j'aurais plutôt mis TS partout. 2:50 Ok, mais dans ce cas tu ne fais que retourner 10 ans en arrière, à l'époque où ton PHP back générait des pages HTML :s 3:17 Oui effectivement, c'est une horreur de react. Mais encore une fois, regarde du coté d'un Framework type Angular, tout est séparé en 4 : html, ts, scss et fichier de test. J'arrête là, mais il y a pas mal de choses qui sont déjà présentes et bien faites dans des technologies plus sérieuses que React. Cela n'enlève rien au caractère passionnant de tout ce que tu as fait, ce sera probablement un outil très pratique pour des cas précis comme le tien :)
Merci pour ton commentaire, oui en effet on peut croire que c'est un retour en arrière, mais j'ai pas eu l'occasion ici de montrer comment intégrer ça avec une page rendue par un serveur, l'idée c'est de se dire que la page doit être rendu avec le html de façon statique et ensuite de la rendre dynamique avec PrunePy. (C'est surtout pratique pour le SEO car le rendu est déjà fait et ça évite de se prendre la tête avec le rendu côté serveur ou client).
Pour le second point, je suis d'accord, y'a tellement de manières différentes pour sortir de la data d'un composant (hooks, composables, store, models, 2 way bindings, events, signaux (composition api avec vue), proxy, provide/inject, etc...) Donc, non la data n'est pas difficilement transmissible entre composants.
3:17 pour ajouter, c'est partiellement faux ce que dit Loïc. On peut faire des tests unitaires sur du react ou du vue sans navigateur. Tu montes ton composant avec du js-dom ou du happy-dom (vitest ou jest utilise ça). Tu peux tester très rapidement et simplement tout ton code.
@@louismazel Oui mais ce que je voulais dire c'est que tu restes dépendant du DOM pour tester une logique qui ne devrait pas l'être, c'est ce que je montre dans l'exemple de fin avec du code, une logique qui est indépendante du DOM
@@LoicRust Tu es dépendant du DOM si tu ne découpes pas bien ton code. Si tu fais des map ou logiques directement dans le JSX, c'est pas le cas oui. Mais un bon code est un code bien découpé et donc testable unitairement. Malgré tout, les tests sur le DOM restent inévitable pour avoir une application bien testée.
C'est incroyable bravo, j'espère qu'un grand nombre puisse y adhérer.
On est là avant que ton framework perce 🎉🎉🎉❤
Merci ! Ça fait chaud au cœur 🤩
C'est une très belle alternative pour ceux qui souhaite rester sous python
Bravo
Super !
Alt Z (ou alors trouver le script d'automatisme) pour formater le texte dans VS Code ou VS Codium(que je préfère).
J'ai hâte de voir la suite
Bravo 👏🏻👍🏻 et je te souhaite une bonne continuation, en tout cas je me suis abonnée pour voir le suivi de ton idée.
Ce serait super de créer maintenant un tutoriel vidéo sur la documentation expliquer page par page en vidéo et faire des projets de site dynamique, de site e-commerce dessus.
C'est beaucoup trop stylé wtf. ça me donne premier degré envie d'utiliser ça comme techno principale. ça t'a pris combien de temps à faire ?
Merci 🥳! La première version je l'ai sortie en 2semaines, puis je l'ai amélioré quand j'avais le temps, le tout fait seulement 220 lignes de code. 😊
Salut Loïc !
Merci pour la vidéo, mais ça fait un moment qu'on attend la suite pour Rust j'ai hâte de découvrir les nouvelles notions pourquoi pas des petits projets....
Super comme projet, ça me fait penser à HTMX mais sans le serveur 👍
Merci, oui le but c'est de rester dans une stack minimaliste
👍
Ta façon de faire est très compréhensible et pédagogique 😊😊😊
Un lien discord pour Rust ???
Si le problème c'est juste de passer des données entre composants de manière générale, tu peux faire un useContext🤦🏾♂️🤦🏾♂️🤦🏾♂️🤦🏾♂️
Si je vais ajouter tailwind je crois les balises seront trop long😢
Justement j'ai quelque chose qui arrive aussi à ce sujet ;)
c'est pas du livewire version python ?
Livewire utilise un serveur back pour gérer la logique, ici tout est géré dans le front
Une chose est de faire découvrir une nouvelle techno, mais c'est une autre chose quand tu essaies de boycotter l'autre. Pour un débutant en React c'est facile de gober cette comparaison, mais pour quelqu'un qui a de l'expérience en React, on voit clairement que tu es loin de comprendre et penser React.
Tellement vrai
0:24 Premier problème, aucun framework dans ta liste. As-tu essayé Angular?
0:40 Oui, c'est le principe. Si tu veux les partager, stocke les dans un service.
2:09 Effectivement, un même langage des deux coté simplifie les choses, et à choisir, j'aurais plutôt mis TS partout.
2:50 Ok, mais dans ce cas tu ne fais que retourner 10 ans en arrière, à l'époque où ton PHP back générait des pages HTML :s
3:17 Oui effectivement, c'est une horreur de react. Mais encore une fois, regarde du coté d'un Framework type Angular, tout est séparé en 4 : html, ts, scss et fichier de test.
J'arrête là, mais il y a pas mal de choses qui sont déjà présentes et bien faites dans des technologies plus sérieuses que React.
Cela n'enlève rien au caractère passionnant de tout ce que tu as fait, ce sera probablement un outil très pratique pour des cas précis comme le tien :)
Merci pour ton commentaire, oui en effet on peut croire que c'est un retour en arrière, mais j'ai pas eu l'occasion ici de montrer comment intégrer ça avec une page rendue par un serveur, l'idée c'est de se dire que la page doit être rendu avec le html de façon statique et ensuite de la rendre dynamique avec PrunePy. (C'est surtout pratique pour le SEO car le rendu est déjà fait et ça évite de se prendre la tête avec le rendu côté serveur ou client).
Pour le second point, je suis d'accord, y'a tellement de manières différentes pour sortir de la data d'un composant (hooks, composables, store, models, 2 way bindings, events, signaux (composition api avec vue), proxy, provide/inject, etc...)
Donc, non la data n'est pas difficilement transmissible entre composants.
3:17 pour ajouter, c'est partiellement faux ce que dit Loïc. On peut faire des tests unitaires sur du react ou du vue sans navigateur. Tu montes ton composant avec du js-dom ou du happy-dom (vitest ou jest utilise ça). Tu peux tester très rapidement et simplement tout ton code.
@@louismazel Oui mais ce que je voulais dire c'est que tu restes dépendant du DOM pour tester une logique qui ne devrait pas l'être, c'est ce que je montre dans l'exemple de fin avec du code, une logique qui est indépendante du DOM
@@LoicRust Tu es dépendant du DOM si tu ne découpes pas bien ton code. Si tu fais des map ou logiques directement dans le JSX, c'est pas le cas oui.
Mais un bon code est un code bien découpé et donc testable unitairement.
Malgré tout, les tests sur le DOM restent inévitable pour avoir une application bien testée.
Arrête le python et dirige toi sur des langages typés
Je fais du Rust 😅