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

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