Design & Développement web - Le topic des canards qui mangent des cookies

[raaaahman]

Bon au final c'était mes déclarations qui étaient erronées, il fallait que je déclare "class" au lieu de "interface" Merci pour vos conseils!

Ça fait un type "any", donc le transpilateur arrêtera de t'emmerder,

J'utilise l'option "noImplicitAny" pour que justement le compilateur me rappelle quand je n'ai pas typé une variable.

Non mais tu peux aussi juste déclarer les types de ta dépendances dans ton projet, pas besoin d'aller modifier la librairie (sauf si tu veux contribuer tes types plus tard).

Vrai, mais dans un cas comme dans l'autre, j'avais la même erreur.

[deathdigger]

Bon au final c'était mes déclarations qui étaient erronées, il fallait que je déclare "class" au lieu de "interface" Merci pour vos conseils!

Pour le coup, c'est logique, une interface ne s'instancie pas.

[William Vaurien]

Des recommandations de ressources (bouquins, sites, ...) pour se remettre à niveau en CSS ?

J'en suis resté au vieux CSS du début des années 2000 et je me sens vraiment à la ramasse dans ce domaine.
Je fais rarement du front, et si c'est le cas c'est pour des formulaires basiques, donc pas un gros besoin, mais là je sens que j'ai atteind une certaine limite et je n'arrive plus à "apprendre sur le tas" en bricolant avec l'inspecteur de code: ça devient de plus en complexe et je suis perdu !

Je pioche des infos à gauche à droite en fonction des besoins, mais il me manque une vision d'ensemble.

[raaaahman]

@deathdigger Merci d'enfoncer le clou...

Présenté comme ça, c'est logique, c'est sûr. Mais utiliser un interface pour typer une classe ça ne vous paraît pas logique aussi? Moins que d'écrire une classe sans implémentation?

EDIT:

@William Vaurien tu peux faire tellement de choses avec le CSS, que c'est difficile de donner une seule et unique ressource. Peut-être que chercher des exemples sur CodePen ou équivalent, en tapant les mot-clés de ce que tu veux créer, regarder le code, et chercher ensuite les propriétés sur MDN sera le meilleur moyen d'atteindre ton but.

En terme de conseils généraux, tu peux te mettre à jour sur la FlexBox ou la Grille (CSS Grid), ce ne sera jamais perdu. Les guides sur CSS Tricks sont assez complets.

[GrandFather]

Des recommandations de ressources (bouquins, sites, ...) pour se remettre à niveau en CSS ?

J'en suis resté au vieux CSS du début des années 2000 et je me sens vraiment à la ramasse dans ce domaine.
Je fais rarement du front, et si c'est le cas c'est pour des formulaires basiques, donc pas un gros besoin, mais là je sens que j'ai atteind une certaine limite et je n'arrive plus à "apprendre sur le tas" en bricolant avec l'inspecteur de code: ça devient de plus en complexe et je suis perdu !

Je pioche des infos à gauche à droite en fonction des besoins, mais il me manque une vision d'ensemble.

Je suis un peu dans le même cas que toi. Je fais de plus en plus de frontend avec Vue.js, et si je me débrouille correctement avec la partie JS, je galère comme un rat mort sur la partie CSS, avec des fondamentaux plus ou moins bien assimilés et le reste acquis à l'arrache.

Mais je pense avoir enfin trouvé LE livre pour repartir sur de bonnes bases et avec une bonne méthodologie : https://www.manning.com/books/css-in-depth

Je ne l'ai pas encore terminé, mais pour l'instant il coche toutes les cases de ce que je recherche. Clair, didactique et bourré de conseils. Et pour ce qui est documentation de référence, je n'ai pas encore trouvé mieux que le MDN : https://developer.mozilla.org/fr/

[William Vaurien]

@William Vaurien tu peux faire tellement de choses avec le CSS, que c'est difficile de donner une seule et unique ressource. Peut-être que chercher des exemples sur CodePen ou équivalent, en tapant les mot-clés de ce que tu veux créer, regarder le code, et chercher ensuite les propriétés sur MDN sera le meilleur moyen d'atteindre ton but.

En terme de conseils généraux, tu peux te mettre à jour sur la FlexBox ou la Grille (CSS Grid), ce ne sera jamais perdu. Les guides sur CSS Tricks sont assez complets.

Je cherche déjà un peu en fonction des besoins ou quand je rencontre une propriété que je ne connais pas. Mais je recherche un truc un peu exhaustif (pas un annuaire non plus) qui couvre les grands thèmes (typiquement FlexBox CSS Grid pour lesquels je suis complétement largué)...
Avant j'aimais bien prendre un bouquin et apprendre tranquillement en le feuilletant et en focalisant sur un point intéressant.

Ca fait des années que je n'ai plus fait ça, mais j'ai l'impression que pour reprendre en main mes connaissances sur les CSS c'est ce qu'il me faudrait.
Les guides de CSS Tricks (je ne connaissais pas du tout !) ont l'air pas mal du tout, mais pas très nombreux, et les articles sont assez éparpillés et semblent orientés vers un truc bien spécifique à chaque fois (donc très bien une fois les bases réaquises).
MDN j'aime bien y aller pour un truc précis, je n'ai pas pris bien le temps de fouiller dans les guides. Ils ont l'air bien aussi.


Petite question, dans mon projet le front utilise un framework Java (Vaadin) qui utilise derrière des WebComponents.
Des sélecteurs css comme ça:

:host([theme~="monTheme"]) [part="items"] ::slotted(content)

c'est standard en css3 ou c'est une surcouche pour les WebComponents ?

- - - Mise à jour - - -

Je suis un peu dans le même cas que toi. Je fais de plus en plus de frontend avec Vue.js, et si je me débrouille correctement avec la partie JS, je galère comme un rat mort sur la partie CSS, avec des fondamentaux plus ou moins bien assimilés et le reste acquis à l'arrache.

Mais je pense avoir enfin trouvé LE livre pour repartir sur de bonnes bases et avec une bonne méthodologie : https://www.manning.com/books/css-in-depth

Je ne l'ai pas encore terminé, mais pour l'instant il coche toutes les cases de ce que je recherche. Clair, didactique et bourré de conseils. Et pour ce qui est documentation de référence, je n'ai pas encore trouvé mieux que le MDN : https://developer.mozilla.org/fr/

Merci pour ce tuyau: j'ai vu qu'il y avait pas mal de livres sur le sujet, mais c'est pas facile d'en trouver un qui réponde vraiment au besoin: je trouve particulièrement difficile de se mettre à jour sur une techno, bien plus que d'apprendre un truc nouveau.
Je le met en wishlist et voir pour me le faire offrir par ma boîte

[GrandFather]

Merci pour ce tuyau: j'ai vu qu'il y avait pas mal de livres sur le sujet, mais c'est pas facile d'en trouver un qui réponde vraiment au besoin: je trouve particulièrement difficile de se mettre à jour sur une techno, bien plus que d'apprendre un truc nouveau.

Absolument, on est face à une offre pléthorique d'ouvrages sur CSS, qui pour l'écrasante majorité exposent la technique sans donner de conseils méthodologiques, ou donnent plein de "recettes" sans exposer les fondamentaux sur lesquels elles s'appuient. Celui-ci fait figure d'exception, en réunissant les deux approches.

A mon sens, ce livre va être pour le CSS ce que "You don't know JS" a été pour le Javascript ; permettre à un faux débutant d'acquérir une base théorique et méthodologique solide.

[raaaahman]

Mais je recherche un truc un peu exhaustif (pas un annuaire non plus) qui couvre les grands thèmes (typiquement FlexBox CSS Grid pour lesquels je suis complétement largué)...

Le problème si tu te lances dans un guide exhaustif sur le CSS c'est qu'il y a des tartines de sélecteurs et de propriétés dont tu ne te serviras peut-être jamais. Tout comme tu as des choix de partir sur une technique plutôt qu'une autre (par exemple, même s'il est possible de mélanger Grille et FlexBox, tu peux tout aussi bien utiliser uniquement celle que tu maîtrise le mieux et faire 100% des choses que tu aurais faites avec l'autre). Pour moi, l'approche "livre de recettes" - que je n'apprécie guère pour la programmation - a plus son sens lorsque l'on cherche à faire du CSS. Surtout si tu ne te spécialises pas dans le front-end/intégration pure.

Des sélecteurs css comme ça:

:host([theme~="monTheme"]) [part="items"] ::slotted(content)

c'est standard en css3 ou c'est une surcouche pour les WebComponents ?

Je ne connais pas bien les WebComponents, mais;

- Les pseudo-sélecteurs :host() et ::slotted() ne me parlent pas du tout
- [theme="monTheme"] et [part="items"] sont des sélecteurs d'attributs en CSS3 (tu peux utiliser le couple [clé="valeur"] que tu veux).

[deathdigger]

@deathdigger Merci d'enfoncer le clou...

Présenté comme ça, c'est logique, c'est sûr. Mais utiliser un interface pour typer une classe ça ne vous paraît pas logique aussi? Moins que d'écrire une classe sans implémentation?

Non mais t'inquiètes, je suis certainement le plus nul du topic en dev web, mais je connais un peu le dev objet
Pour bien faire, faudrait faire une interface et une ou plusieurs classes.

[Captain_Cowkill]

Pour le CSS je vous recommande chaudement la chaîne YT de Kevin Powell https://www.youtube.com/kepowob

[raaaahman]

Y'a pas d'soucis.

Si l'on parle d'un fichier d'implémentation TypeScript, oui toutes les règles de la POO s'appliquent. Mais je suis en train de découvrir les fichiers de déclarations TypeScript, en gros pour introduire du typage sur les fichiers non-typé JS. Et j'ai du mal à saisir le fonctionnement du compilateur...

[Fastela]

Je ne sais pas lesquelles tu utilises, mais Element+ me semble très bien intégrer Vue3.

J'ai utilisé Element (avec Vue 2) pendant presque un an, et là je suis passé sur Element+ (avec Vue 3) sur un projet enfant.

Element ça marche plutôt bien, mais il faut avouer un truc : le fait que ce soit un framework chinois, c'est très difficile de trouver des réponses aux problèmes qu'on rencontre. Leur repo Github est bordélique comme pas possible, avec des issues qui sont même pas traîtées par un bot, et 90% rédigées en chinois.

J'ai aussi rencontré pas mal de problèmes avec des composants, notamment au niveau CSS.

Une autre solution serait de passer sur un truc genre Tailwind et construire mes propres composants, mais l'abstraction de faire du style dans des classes utilitaires ça me laisse un petit goût de vomi dans la bouche à chaque fois que je vois du code.

J'ai un nouveau taff et je fais un peu de R&D en utilisant le framework API Platform et franchement c'est plus que pas mal.

J'ai un peu de la peine à imaginer comment on peut avoir un truc plus efficace. Il y a juste la façon d'attacher du code métier à une action qui me chiffonne.

API Platform c'est VRAIMENT bien. J'ai eu l'occasion de discuter avec Kevin Dunglas lors d'une conférence, c'est un mec super intéressant, et le boulot qu'il fait avec Les Tilleuls est dingue. D'ailleurs la API Platform conference était la semaine dernière.

Ceci dit, pour l'avoir utilisé un peu, tu as trouvé ce qui m'a tout de suite gêné : c'est vite chiant quand tu veux attacher du code métier comme tu dis. Une API c'est pas uniquement un CRUD et il y a toujours des subtilités qui sont difficile de faire rentrer dans l'écosystème API Platform. Ou alors ça demande un cahier des charges tellement détaillé et vérouillé que tu sais exactement ce dont tu vas avoir besoin. On sait que ce genre de choses n'existe pas. :D

[GrandFather]

Pour le CSS je vous recommande chaudement la chaîne YT de Kevin Powell https://www.youtube.com/kepowob

Alors ça doit être une question de génération - et aussi sans doute d'âge - mais je suis incapable d'acquérir un socle - des techniques, tout au plus - de connaissances par vidéo. Il me faut de l'écrit.

[Awake]

CSS n'a pas tant évolué que ça. En gros tu apprends à te servir de flex et c'est bon. Il y a un million de nouveaux attributs pour faire tout et n'importe quoi, mais ils s'apprennent bien au fil de l'eau.

Edit : bon ok les media queries aussi

[GrandFather]

J'ai aussi rencontré pas mal de problèmes avec des composants, notamment au niveau CSS.

J'ai rencontré jusqu'ici peu de problèmes, la librairie est plutôt bien suivie. Mais je te rejoins pour la partie CSS, pratiquement pas documentée. Pour changer l'apparence d'un composant, c'est un peu la galère...

Ceci dit, pour l'avoir utilisé un peu, tu as trouvé ce qui m'a tout de suite gêné : c'est vite chiant quand tu veux attacher du code métier comme tu dis. Une API c'est pas uniquement un CRUD et il y a toujours des subtilités qui sont difficile de faire rentrer dans l'écosystème API Platform. Ou alors ça demande un cahier des charges tellement détaillé et vérouillé que tu sais exactement ce dont tu vas avoir besoin. On sait que ce genre de choses n'existe pas. :D

Personnellement ça ne m'a jamais entravé, il y a suffisamment de points d'extension à disposition pour couvrir tous les besoins métiers. On peut notamment le faire en décorant les services proposés par défaut, ou s'orienter vers une logique complètement custom avec les processeurs d'état.

[Getz]

Pour les flex-box en CSS, je trouve ce guide de css-tricks vraiment pratique et didactique, j'y reviens souvent lorsque j'ai un petit trou de mémoire sur une propriété:

https://css-tricks.com/snippets/css/a-guide-to-flexbox/

[William Vaurien]

Alors ça doit être une question de génération - et aussi sans doute d'âge - mais je suis incapable d'acquérir un socle - des techniques, tout au plus - de connaissances par vidéo. Il me faut de l'écrit.

pareil, les video c'est pour voir comment démonter mon filtre de machine à laver ou pour apprendre à poser un joint de douche proprement (protip: ça ne marche jamais comme sur la video!)

Mais après je comprends que ça fonctionne mieux pour ce genre de format pour certains.

[William Vaurien]

CSS n'a pas tant évolué que ça. En gros tu apprends à te servir de flex et c'est bon. Il y a un million de nouveaux attributs pour faire tout et n'importe quoi, mais ils s'apprennent bien au fil de l'eau.

Edit : bon ok les media queries aussi

Dans mes souvenirs le css du début 2000 était assez bordelique dans sa mise en oeuvre: il y avait pas mal de différences subtiles entre navigateur qui te pourrissaient les mises en forme, et comme c'était mal maîtrisé par les dev ça finnissait à coup d' "!important" crados et de feuilles css immondes de 10000 lignes copiées-collées (parfaitement assorti au js de l'époque...)
Après c'était relativement simple avec une palette d'attributs assez limitée, mais il y avait quand même des trucs "simples" finalement dur à réaliser (composant prenant toute la hauteur de la fenêtre par exemple...).

Ensuite je suis passé en dev back quasi à 100% et j'ai suivi les évolutions de loin, comme l'apparition de "para-langages" css (genre less css) et comme j'ai toujours aimé bricoler l'aspect de mes pages web préférés avec des plugins genre Stylus j'ai un peu gardé la main. Mais plus ça va moins j'y arrive. Le placement des composants me semble beaucoup moins intuitif qu'avant et les résultats de mes tâtonnements me semblent complétement aberrants. Pareil sur mes projets avec un peu de front: les composants embarqués par notre framework me semble de plus en plus complexent à modifier et les résultats d'interactions entre plusieurs éléments m'est de plus en plus difficile à comprendre.

Les différences sont subtiles, mais si le css3 dans sa syntaxe et son comportement est très proche du vieux css, la prise en main me semble plus délicate et surtout il me semble qu'il y a eu une rationalisation des comportement (passage de 'hack' vers des modèles genre 'flex' ou grid) qui demande un peu de recul pour bien comprendre et utiliser. Et du coup je cherche à intégrer les nouveaux fonctionnements de manière plus globale plutôt que d'essayer de comprendre au coup par coup.

[Captain_Cowkill]

Alors ça doit être une question de génération - et aussi sans doute d'âge - mais je suis incapable d'acquérir un socle - des techniques, tout au plus - de connaissances par vidéo. Il me faut de l'écrit.

Bah tu mets pause quand il écrit le code
Et tu fais comme moi, tu prends des notes. J'ai un Notion que je partage avec les collègues où je mets plein de tips (pas que pour le CSS évidemment).

[Awake]

Dans mes souvenirs le css du début 2000 était assez bordelique dans sa mise en oeuvre: il y avait pas mal de différences subtiles entre navigateur qui te pourrissaient les mises en forme, et comme c'était mal maîtrisé par les dev ça finnissait à coup d' "!important" crados et de feuilles css immondes de 10000 lignes copiées-collées (parfaitement assorti au js de l'époque...)
Après c'était relativement simple avec une palette d'attributs assez limitée, mais il y avait quand même des trucs "simples" finalement dur à réaliser (composant prenant toute la hauteur de la fenêtre par exemple...).

Ensuite je suis passé en dev back quasi à 100% et j'ai suivi les évolutions de loin, comme l'apparition de "para-langages" css (genre less css) et comme j'ai toujours aimé bricoler l'aspect de mes pages web préférés avec des plugins genre Stylus j'ai un peu gardé la main. Mais plus ça va moins j'y arrive. Le placement des composants me semble beaucoup moins intuitif qu'avant et les résultats de mes tâtonnements me semblent complétement aberrants. Pareil sur mes projets avec un peu de front: les composants embarqués par notre framework me semble de plus en plus complexent à modifier et les résultats d'interactions entre plusieurs éléments m'est de plus en plus difficile à comprendre.

Les différences sont subtiles, mais si le css3 dans sa syntaxe et son comportement est très proche du vieux css, la prise en main me semble plus délicate et surtout il me semble qu'il y a eu une rationalisation des comportement (passage de 'hack' vers des modèles genre 'flex' ou grid). Et du coup je cherche à intégrer les nouveaux fonctionnements de manière plus globale plutôt que d'essayer de comprendre au coup par coup.

Ha oui c'est sûr que c'est plus simple maintenant qu'il y a en gros tous les navigateurs sont sous chromium ou firefox, qui sont tous les deux bien à jour niveau CSS (bon il y a Safari qui se débat dans son coin, on essaie de l'oublier). Plus trop besoin de hack ou de vérifier en permanence si tout est bien compatible, sauf pour les attributs CSS exotiques.

La seule méthodo CSS que je connaisse, c'est BEM, et franchement je la trouve non seulement inutile mais carrément handicapante (on se retrouve avec des sélecteurs de 300 caractères qui alourdissent énormément le poids du fichier CSS final).

Comme pre-processeur, je te recommanderais d'apprendre SASS plutôt que LESS, je crois que c'est lui qui a gagné la guerre.

[Captain_Cowkill]

Oui, SASS c'est vraiment trop bien.

[William Vaurien]

Notre framework front est revenu à l'utilisation de css "vanille" après un passage par SASS.
L'utilisation combinée des variables css (encore un truc nouveau pour moi) et de composants web semble avoir fortement diminué l'intérêt d'un pre-processeur.

Par methodo je voulais parler d'ensemble d'attributs fonctionnant ensemble pour former un ensemble cohérent (ce qui n'était pas le cas avant), comme les attributs pour les 'grids'.

[Dross]

Des recommandations de ressources (bouquins, sites, ...) pour se remettre à niveau en CSS ?

J'en suis resté au vieux CSS du début des années 2000 et je me sens vraiment à la ramasse dans ce domaine.
Je fais rarement du front, et si c'est le cas c'est pour des formulaires basiques, donc pas un gros besoin, mais là je sens que j'ai atteind une certaine limite et je n'arrive plus à "apprendre sur le tas" en bricolant avec l'inspecteur de code: ça devient de plus en complexe et je suis perdu !

Je pioche des infos à gauche à droite en fonction des besoins, mais il me manque une vision d'ensemble.

Voici la ressource que j'ai mis dans les mains de mon équipe : https://www.udemy.com/course/advanced-css-and-sass/
(et qui m'a permis de me mettre à jour rapidement aussi : autant techno que petites astuces et habitudes de devs)


Pour le CSS/SASS, juste pour le nesting je ne pourrai plus repartir sur du CSS, devoir tout répéter sans arrêt...

[poneyroux]

Voici la ressource que j'ai mis dans les mains de mon équipe : https://www.udemy.com/course/advanced-css-and-sass/
(et qui m'a permis de me mettre à jour rapidement aussi : autant techno que petites astuces et habitudes de devs)


Pour le CSS/SASS, juste pour le nesting je ne pourrai plus repartir sur du CSS, devoir tout répéter sans arrêt...

Jonas

[raaaahman]

Notre framework front est revenu à l'utilisation de css "vanille" après un passage par SASS.
L'utilisation combinée des variables css (encore un truc nouveau pour moi) et de composants web semble avoir fortement diminué l'intérêt d'un pre-processeur.

Ca m'a l'air d'être plus proche de la tendance actuelle, oui. Le Sass c'était sûrement le feu dans les pages qui faisaient de l'AJAX en jQuery dans les années 2010, mais aujourd'hui avec tous les frameworks front orientés composants (React, Vue, Angular?, Svelte?, Polymer, etc.), les techniques pour faire du CSS modulaire se sont diversifiées. Est-ce que c'est forcément mieux? J'en sais rien. Ceci dit si c'est pour une mise à jour, autant commencer par l'état des lieux.

[Captain_Cowkill]

Pour le CSS/SASS, juste pour le nesting je ne pourrai plus repartir sur du CSS, devoir tout répéter sans arrêt...

Voilà !

[Orhin]

Je ne connais pas bien les WebComponents, mais;

- Les pseudo-sélecteurs :host() et ::slotted() ne me parlent pas du tout

C'est lié aux WebComponents et à leur shadow-dom : https://developer.mozilla.org/en-US/docs/Web/CSS/:host

En gros quand tu as une feuilles de style associée à ton WebComponent dont le contenu ne sera appliqué qu'à lui (grâce au shadow-dom), ça te permet de cibler l'élément qui représente le WebComponent depuis la dite feuille de style (sans avoir besoin d'id/classe ou élément wrapper spécifique donc).

CSS n'a pas tant évolué que ça. En gros tu apprends à te servir de flex et c'est bon. Il y a un million de nouveaux attributs pour faire tout et n'importe quoi, mais ils s'apprennent bien au fil de l'eau.

En vrai c'est pas totalement faux.
Si je ne devrais retenir que 4 éléments du CSS "moderne" ce serait : flex, grid, media queries et variables (aussi appelés custom-properties).

Pour le CSS/SASS, juste pour le nesting je ne pourrai plus repartir sur du CSS, devoir tout répéter sans arrêt...

Perso ce que je préfère maintenant c'est l'approche styled-componant avec des trucs style https://emotion.sh/docs/introduction.

Ça permet de facilement injecter des valeurs dynamiques depuis tes inputs/props.

les techniques pour faire du CSS modulaire se sont diversifiées.

Ça devient quand même verbeux très rapidement, surtout si t'utilises pas mal de sélecteurs/modificateurs sur une classe de base.

[tenshu]

API Platform c'est VRAIMENT bien. J'ai eu l'occasion de discuter avec Kevin Dunglas lors d'une conférence, c'est un mec super intéressant, et le boulot qu'il fait avec Les Tilleuls est dingue. D'ailleurs la API Platform conference était la semaine dernière.

Ceci dit, pour l'avoir utilisé un peu, tu as trouvé ce qui m'a tout de suite gêné : c'est vite chiant quand tu veux attacher du code métier comme tu dis. Une API c'est pas uniquement un CRUD et il y a toujours des subtilités qui sont difficile de faire rentrer dans l'écosystème API Platform. Ou alors ça demande un cahier des charges tellement détaillé et vérouillé que tu sais exactement ce dont tu vas avoir besoin. On sait que ce genre de choses n'existe pas. :D

Jusque là j'étais vraiment pas convaincu par la solution qu'ils indiquait dans la doc à savoir étendre une classe interne type serializer et mettre un Switch dedans sur le type d'objet et le type d'opération pour attacher un truc.
Ou utiliser la pattern CQRS en gérant complétement de façon asynchrone les opérations.

Mais ils viennent de sortir une v3 là il y a 4 jours et ils se sont un peu penché sur la question. Ils ont mis à jour la doc en conséquence
https://api-platform.com/docs/core/dto/

A la conférence qui se tenait pour l'occasion il y a même eu une présentation sur l'application du DDD avec la v3
https://speakerdeck.com/mtarld/api-p...api-platform-3

C'est intéressant mais :
- ça reste complexe, il faut vraiment bien piger l'architecture hexagonale
- le gars sépare strictement les opérations qui sont en mode RAD donc gérées complétement par l'API plateforme de celles qui sont custom et qui vont utiliser leurs propres providers en suivant le DDD

C'est cool mais si je veux juste ajouter juste un comportement en plus sur un paquet de route ça me semble que ça peut été galère. Il faut que je teste mais à mon avais utiliser le composant Messenger ça me semble plutôt cool.
https://api-platform.com/docs/core/messenger/

[Dross]

Perso ce que je préfère maintenant c'est l'approche styled-componant avec des trucs style https://emotion.sh/docs/introduction.

Ça permet de facilement injecter des valeurs dynamiques depuis tes inputs/props.

Ah ce mélange logique / rendu me gène à chaque fois que je le vois (ptite vibe php en plus), je préfère largement une séparation claire et physique des responsabilités. Mais c'est sûr que ça peut avoir des avantages.

[raaaahman]

Quelle logique? Au final HTML + CSS + JS c'est beaucoup de l'UI. Les données se sont enfuies du HTML depuis que l'on a commencé à utiliser du templating (c'est pas neuf). Quand au JavaScript, historiquement il a surtout servi à faire des interactions du type liste déroulante, input qui clignote, (des choses qui auraient pu être faites en CSS) et également à rafraichissement d'un bout de page quand les données changent...

Aujourd'hui il me semble que la séparation la plus importante est entre le JS qui fait juste de l'UI, de celui qui gère les requêtes/données, de celui qui (éventuellement) contient de la logique métier.

@Orhin Quelle est la méthode verbeuse pour toi? Sachant que dans "les techniques", j'inclus les styled-components justement.

D'ailleurs je les ai utilisés dans mon dernier projet, je n'ai pas l'impression que le gain en terme de modularité/réutilisation a été si important que cela ua final. Peut-être que c'est le projet qui ne s'y prête pas... Par contre, je me demande si l'évaluation des variables ne me consomme pas quelques ressources durant l'éxécution, ce qui serait dommage vu que je les ai surtout utilisées pour faire du "theming" (thématisation? thémage? te-ma mon thème?).