J'ai rien compris mais comme t'explique ça à l'air tellement facile avec toi ^^ J'apprend PHP et JS grave à t'es vidéo un jour j'arriverai peut être à cet étape qui sais ! :p Merci pour t'es vidéo qui sont très utiles et bien faites :)
Merci grafikart je galérais à chercher une telle api sur vue. je crois que je vais très vite m'arrimé à cette api. et si vue 3 l'intègre complètement ce sera la bienvenue
Je ne suis pas sûr de comprendre l’avantage par rapport aux mixins qui étaient déja un pattern de trait/composition assez puissant. Par contre faut reconnaitre que la nouvelle api rend le code plus explicite, plus déclaratif, moins « magique » et potentiellement mieux testable, un peu a l’image de react. J’ai quand même un peu peur que la hype de cette nouvelle api tente les développeurs à abuser de la composition en créant des concerns pour la moindre petite logique, les god components risquent de se transformer en conteneurs de traits, avec chacun leur propre logique encapsulée et qui devront fonctionner tous ensemble sans entrer en conflit. Il va falloir beaucoup de rigueur pour utiliser cette API correctement (notament des conventions comme tu l’a cité) et surtout ne pas tomber dans le piège de l’overdesign, car trop de composition risque d’apporter un lot de complexité contre-productif et inutile.
C'est dommage, vuejs était un oasis de simplicité qui semble déjà s'assécher. En donnant autant de liberté à des devs plus ou moins pertinents, on n'aura pas 2 composants organisés de la même manière. Chacun va planquer son code à sa manière. On va perdre énormément de temps à piger la logique des composants. Là où on avait une structure de code stable qui permettait de rendre n'importe quel composant facilement lisible, modifiable et réutilisable.
@@picatchumm64 Non, Svelte te donne déjà la liberté d'organiser le code comme tu le souhaites, tu n'as pas de fonctions clefs pour tes composants comme Pierre Alain le mentionne.
Je suis bien d'accord avec toi et du coup les gens commence à définir des conventions de nommages, ça induit qu'il est plus difficile de s'y retrouver.
Organiser le code comme on le souhaite est biais général de la programmation qui, sur le long terme apporte plus d'avantages que d'inconvénient. Il suffit de regarder le nombre de design pattern qui existe aujourd'hui et continuent d'évoluer. La séparation de code est pour moi la base d'un code scalabe. Plus avec la communauté on trouvera forcement un pattern pour organiser l'api composition dans les projets Vue.js
Le principe est en soi intéressant et pas trop mal expliqué. Mais cela me semble trop permissif et propice à rendre la chose trop abstraite / technique pour des codeurs, comme toi, qui rendront la chose innacessible pour le lambda. Preuve en est dans ta vidéo. C'est sans doute intéressant du point de vue logique et optimisation (en terme de réutilisation), mais ça devient vite de la fioriture qui ne semble, au final, être distrayant que pour ta seule personne. Sans vouloir me montrer désobligeant.
![Vue 3 Composition API Introduction [FULL TUTORIAL]](http://i.ytimg.com/vi/bwItFdPt-6M/mqdefault.jpg)
J'ai rien compris mais comme t'explique ça à l'air tellement facile avec toi ^^
J'apprend PHP et JS grave à t'es vidéo un jour j'arriverai peut être à cet étape qui sais ! :p
Merci pour t'es vidéo qui sont très utiles et bien faites :)
Merci grafikart je galérais à chercher une telle api sur vue. je crois que je vais très vite m'arrimé à cette api. et si vue 3 l'intègre complètement ce sera la bienvenue
Je trouve que c'est une très bonne idée l'API Composition ! on va pouvoir être plus libre j'ai l'impression
Très intéressant tout ça. On ne pourrait pas "composer" autoIncrementer à partir d'incrementer pour reutiliser la logique ?
Ca a lair cool. Jutilise toujours les actions du store pour fetch perso
Hello, super vidéo, petite question tous doit être fonction ? C’est une convention ou... peut on pas juste créer des objets et les exports ?
Je ne suis pas sûr de comprendre l’avantage par rapport aux mixins qui étaient déja un pattern de trait/composition assez puissant. Par contre faut reconnaitre que la nouvelle api rend le code plus explicite, plus déclaratif, moins « magique » et potentiellement mieux testable, un peu a l’image de react. J’ai quand même un peu peur que la hype de cette nouvelle api tente les développeurs à abuser de la composition en créant des concerns pour la moindre petite logique, les god components risquent de se transformer en conteneurs de traits, avec chacun leur propre logique encapsulée et qui devront fonctionner tous ensemble sans entrer en conflit. Il va falloir beaucoup de rigueur pour utiliser cette API correctement (notament des conventions comme tu l’a cité) et surtout ne pas tomber dans le piège de l’overdesign, car trop de composition risque d’apporter un lot de complexité contre-productif et inutile.
Merci pour cette vidéo. Très bon contenu
Merci pour les tutos
Il existe un site ou sont partagé des composants ? Comme ça a l'air simple d'avoir des fonctionnalités réutilisables avec ça.
C'est moi où ça ressemble bcp à l'utilisation des Hooks de React ?
C'est dommage, vuejs était un oasis de simplicité qui semble déjà s'assécher. En donnant autant de liberté à des devs plus ou moins pertinents, on n'aura pas 2 composants organisés de la même manière. Chacun va planquer son code à sa manière. On va perdre énormément de temps à piger la logique des composants. Là où on avait une structure de code stable qui permettait de rendre n'importe quel composant facilement lisible, modifiable et réutilisable.
mais merci beaucoup pour la présentation :)
@@picatchumm64 Non, Svelte te donne déjà la liberté d'organiser le code comme tu le souhaites, tu n'as pas de fonctions clefs pour tes composants comme Pierre Alain le mentionne.
Je suis bien d'accord avec toi et du coup les gens commence à définir des conventions de nommages, ça induit qu'il est plus difficile de s'y retrouver.
Organiser le code comme on le souhaite est biais général de la programmation qui, sur le long terme apporte plus d'avantages que d'inconvénient. Il suffit de regarder le nombre de design pattern qui existe aujourd'hui et continuent d'évoluer. La séparation de code est pour moi la base d'un code scalabe. Plus avec la communauté on trouvera forcement un pattern pour organiser l'api composition dans les projets Vue.js
Je suis triste que ca va s'arreter data , computed , watch...😅😥😥
Le principe est en soi intéressant et pas trop mal expliqué. Mais cela me semble trop permissif et propice à rendre la chose trop abstraite / technique pour des codeurs, comme toi, qui rendront la chose innacessible pour le lambda. Preuve en est dans ta vidéo. C'est sans doute intéressant du point de vue logique et optimisation (en terme de réutilisation), mais ça devient vite de la fioriture qui ne semble, au final, être distrayant que pour ta seule personne. Sans vouloir me montrer désobligeant.
Ne t'inquiète pas je ne le prends pas mal. Avec le recul je partage au final ton avis, l'écriture génère plus de problème que de solutions :(