Symfony UX et le frontend

Transcript

1. Symfony UX et le frontend, cette épopée
2. Sommaire 01 - UX ? DX ? Et l’UI ? 02 - En théorie, c’est pratiquement pratique 03 - Chougner, c’est bien parfois 01
3. User or Developer experience
4. Du PHP dans du JS
5. PHPception UX répond à un(e) besoin / envie: Faire du frontend en tant que dev back aisément UX implémente ce besoin via une API PHP optionnelle exposée au frontend via Twig Traduction niaise: Je veux faire du React sans JSX via PHP
6. La théorie, c’pratique UX est une initiative, voyez cela comme un coffre à jouet, débrouillez-vous avec ce que l’on vous offre Au fond, le tout n’est qu’une décoration “++” de Stimulus / Turbo Une classe, un composant, simple, basique … Enfin, oui et non.
7. Sandwich time Classe PHP (#[As*Component])* Template Twig Contrôleur Stimulus Contrôleur personnalisé Couche UX / Twig / Sf Couche Stimulus Librairies externes *Oui, les composants anonymes existent, c’pas le débat
8. En pratique
9. Tout cramer
10. Migrer, en secret Migration d’un dashboard de rédaction pour LEP, backend en Symfony / JS maison / UX JS complexe et découpé en “modules” (aka “composants React” sans React) Objectif : Intégrer une recherche via moteur de recherche avec failover sur la DB (Postgres)
11. On est mal chef Formulaire de recherche Résumé d’une publication Filtres Filtres Filtres Datepicker Pagination Pagination rapide Indicateurs Limite Icon Résumé d’une publication Icon Résumé d’une publication Icon Résumé d’une publication Icon Actions Actions Actions Actions
12. Houdini (version 2024) Formulaire de recherche Résumé d’une publication Filtres Filtres Filtres Datepicker LiveComponent TwigComponent / Template Pagination Pagination rapide Indicateurs Limite Icon Résumé d’une publication Icon Résumé d’une publication Icon Résumé d’une publication Icon Actions Actions Actions Actions
13. Hold on, wait a minute Communication inter-composants, suivi d’état, morphing, “sous-events”, what the hell?! Si la recherche “filtre”, les filtres doivent aussi réduire le scope, idem pour la limite, le tout combiné si possible. Comment fait-on communiquer tout ça sans imploser en plein vol ?
14. Le doute m’habite Formulaire de recherche Résumé d’une publication Filtres Filtres Filtres Datepicker Trigger Pagination Pagination rapide Indicateurs Limite Icon Résumé d’une publication Icon Résumé d’une publication Icon Résumé d’une publication Icon Receiver Actions Actions Actions Actions
15. Douter, c’est tester
16. ExperimentationHub Première ébauche avec X composants s’écoutant entre eux Performances aux fraises, zéro stabilité, découpage trop fin Gestion des ids catastrophique (f*** conventions), morphing en carafe data-skip-morph to the rescue, enfin … Si X composant s’écoutent, privilégier (si possible) les composants nested Si le composant Y dépend de X et que Z update Y, quid de X ?
17. Are you listening? La recherche coordonne le tout (enfin, les filtres aussi) Emission d’un event “search” qui est écouté par un seul composant Si un composant enfant effectue une MAJ via un event, on recalcule tout Emission vers composant spécifique Si le composant ne déclenche pas un nouveau rendu, on est mal X petits composants qui hérite des données du composant maître Reste la solution du debouncing mais perte de précision
18. Moment doléances
19. Are you listening? Un composant peut émettre un event écouté par X composants Aucun moyen natif de prioriser les composants déclenchés Si un composant n’a pas terminé son rendu, quid de l’état ? Une solution serait d’avoir une option priority Laisser faire et vérifier l’état dans le controller Stimulus via on() Si X composants à rendre à nouveau, coucou /_batch Si sous-émission, attention aux rendu cumulés
20. What’s a component? Un composant contient des données envoyées à la vue Serialization peu intuitive (serializer, hydrator, prière ?) Méthode ou LiveProp, il faut choisir LiveProp sur types scalaires / DTO Par convention, privilégier les hydrators pour les objets
21. Matrioshka powar Un composant représente une section atomique d’un template Attributs ou LiveProp, là réside la question Rendu en cascade si attributs partagés Utiliser mount ou postMount pour les données complexes Eviter de modifier les données via LiveListener Se méfier de la satanerie diabolique updateFromParent
22. Time to test Plusieurs composants dans un même template ? Oh boy LiveComponent + composants imbriqués, librairie E2E TwigComponent, bridge PHPUnit suffisant Si tests simples, trait InteractsWithLiveComponents Cypress ou Playwright (Panther trop lent) Bien penser aux mocks / spies d’appels réseaux et prier
23. What about… speed? Chaque rendu déclenche un appel kernel, résolution des attributs / metadata, etc Limiter les appels cumulés sur un seul template Defer / Lazy, tout dépend du contexte Si composants caché, lazy est ton ami Désactiver le morphing si composants enfants / complexes En pratique, UX est lent, adaptez-vous
24. Fini de râler ?
25. It depends, a lot… Symfony UX est une bonne idée mais la mise en pratique reste ardue Si votre application vit très bien sans, passez votre chemin Doliprane (ou Efferalgan), 3 fois par jour, la documentation et du café / thé Si vous êtes sur une refonte, réfléchissez bien et faites un POC, ça coûte rien (enfin …)
26. Des bisous