Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Développer un client riche React dans un projet Symfony 4

Développer un client riche React dans un projet Symfony 4

364d59ac0b4b4e5eee8aeb27a127d176?s=128

Titouan Galopin

December 18, 2018
Tweet

Transcript

  1. Développer un client riche React dans un projet Symfony 4

    Titouan GALOPIN Product Manager SymfonyInsight SfPot Décembre 2018 Deezer 1
  2. Agenda 1. Introduction 2. Mais au fait, pourquoi on développe

    des clients riches ? 3. Quand les clients riches tournent mal 4. Un client riche dans Symfony 4 2
  3. Ce talk est une analyse de mes expériences : c’est

    mon opinion ! Disclaimer 3
  4. Client riche = logique métier côté client Introduction 4

  5. En Web React, Vue, Angular, … Dialogue via HTTP avec

    une API Introduction 5
  6. 2. Mais au fait, pourquoi on développe des clients riches

    ? 6
  7. Les utilisateurs ont développé de nouvelles attentes 7

  8. - Chargement rapide 8

  9. - Chargement rapide - Interfaces qui les aide et les

    accompagne 9
  10. - Chargement rapide - Interfaces qui les aide et les

    accompagne - Formulaires efficaces et facile d’utilisation 10
  11. - Chargement rapide - Interfaces qui les aide et les

    accompagne - Formulaires efficaces et facile d’utilisation - Réutilisation de patterns d’UI d’autres sites 11
  12. - Chargement rapide - Interfaces qui les aide et les

    accompagne - Formulaires efficaces et facile d’utilisation - Réutilisation de patterns d’UI d’autres sites - Multiples clients sur différents appareils 12
  13. - Chargement rapide - Interfaces qui les aide et les

    accompagne - Formulaires efficaces et facile d’utilisation - Réutilisation de patterns d’UI d’autres sites - Multiples clients sur différents appareils 13 Expérience utilisateur Presque expérience utilisateur
  14. Les clients riches sont utiles pour améliorer l’expérience utilisateur 14

  15. Si développer un client riche n’améliore pas l’expérience utilisateur, cela

    n'apporte que des inconvénients 15
  16. 3. Quand les clients riches tournent mal 16

  17. Les requêtes HTTP sont très peu fiables 17

  18. Combien de fois est-ce qu’un appel de méthode PHP ne

    fonctionne pas, de manière aléatoire ? 1 fois sur 1 000 000 000 ? 1 fois sur 1 000 000 000 000 000 000 ? En pratique, jamais ? 18
  19. Un SLA de 99.999% = 1 erreur sur 100 000

    requêtes 19
  20. Risques d’erreurs plus élevé => nécessité de mieux gérer les

    erreurs => complexité additionnelle 20
  21. Le navigateur fait beaucoup de travail pour vous 21

  22. Quand est la dernière fois que vous avez eu besoin

    de développer votre propre gestion de session en PHP ? En pratique, jamais ? 22
  23. Se baser sur les navigateurs pour gérer l’historique, la session

    ou les cookies simplifie énormément votre code 23
  24. Ne plus se baser sur les comportements natifs des navigateurs

    (JWT, react-router, ...) => nécessité de beaucoup redéfinir soit même => complexité additionnelle 24
  25. Le front-end est un autre métier 25

  26. Combien de développeurs(ses) dans votre équipe maîtrisent parfaitement à la

    fois React et Symfony ? Tous ? La moitié ? Seulement quelque uns ? 26
  27. Une application interactive implique une façon de développer différente =>

    il faut des compétences spécifiques => complexité humaine additionnelle 27
  28. Comment lutter contre ces nouvelles sources de complexité ? 28

  29. Ne pas utiliser de client riche si cela n’améliore pas

    de manière significative l’expérience utilisateur 29
  30. Savoir faire une balance entre expérience utilisateur et dette technique

    additionnelle 30
  31. Utiliser des (petits) clients riches uniquement là où c’est utile

    (et oui, peut-être que c’est utile pour toute votre application, mais pas forcément) 31
  32. 4. Un client riche dans Symfony 4 32

  33. A titre personnel, j’utilise généralement 1 de ces 3 niveaux

    d’intégration selon le projet 33 Pas de Javascript ou VanillaJS React seul sur certains composants spécifiques Single Page App complète React + React-Router + Redux
  34. Webpack Encore est absolument génial 34

  35. 35 {% block stylesheets %} {{ encore_entry_link_tags('user-registration') }} {% endblock

    %} {% block javascripts %} {{ encore_entry_script_tags('user-registration') }} {% endblock %} Twig + Vanilla JS
  36. 36 <div id="react"> Hello world </div> // user-registration.js render(<div>Overriden!</div>, document.getElementById('react'));

    Twig + React React écrase le HTML original : progressive enhancement
  37. 37 <script type="application/json" type="app-data"> {{ twig_data|json_encode }} </script> Twig +

    React Pas nécessairement besoin d’API
  38. 38 Single Page App API-platform + create-react-app : deux possibilités

  39. 39 Single Page App API-platform + create-react-app : deux possibilités

    Deux dossiers distincts dans le repository Idéal dans le cas de noms de domaine différent
  40. 40 Single Page App API-platform + create-react-app : deux possibilités

    Deux dossiers distincts dans le repository Idéal dans le cas de noms de domaine différent React intégré dans Symfony Utilise Symfony comme proxy (route wildcard vers Twig qui appelle l’app React)
  41. 41 Deux dossiers distincts ├── api │ ├── bin │

    ├── config │ ├── public │ ├── src │ ├── var │ └── vendor └── client ├── node_modules ├── public └── src
  42. 42 React intégré dans Symfony /** * @Route("/app") * @Route("/app/{wildcard}",

    requirements={"wildcard"=".+"}) */ public function appAction(): Response { return $this->render('react-app-index.html.twig'); }
  43. 43 Pas de Javascript ou VanillaJS React seul sur certains

    composants spécifiques Single Page App complète React + React-Router + Redux Symfony gère l’état et la logique métier Utilisation de JS comme progressive enhancement Client complexe qui gère l’état et la logique métier API-platform, React, React-Router, Redux
  44. 44 Pas de Javascript ou VanillaJS React seul sur certains

    composants spécifiques Single Page App complète React + React-Router + Redux Logique métier : PHP Routing : Symfony Vue : Twig Stockage : Doctrine Logique métier : PHP Routing : Symfony Vue : Twig + React Stockage : Doctrine Logique métier : JS Routing : React-Router Vue : React Stockage : API-platform
  45. Attention au SEO ! 45

  46. Attention au SEO ! Aujourd’hui, la plupart des robots d’indexation

    comprennent bien les applications Javascript 46
  47. Pour un site à fort trafic : Server-Side Rendering Sinon

    : pas forcément nécessaire 47
  48. Limenius/ReactBundle pour le Server-Side Rendering 48

  49. Conclusion 49

  50. 50 Pas de Javascript ou VanillaJS React seul sur certains

    composants spécifiques Un entrypoint JS par page Progressive enhancement via JS/React Très fiable et flexible car basé sur HTTP et le navigateur
  51. 51 Pas de Javascript ou VanillaJS React seul sur certains

    composants spécifiques Single Page App complète React + React-Router + Redux Un entrypoint JS par page Progressive enhancement via JS/React Très fiable et flexible car basé sur HTTP et le navigateur API + client riche Projets séparés Plus complexe car redéfinit des comportements natifs
  52. Merci ! Questions ? Titouan GALOPIN Product Manager SymfonyInsight SfPot

    Décembre 2018 Deezer 52