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

Slide 1

Slide 1 text

Développer un client riche React dans un projet Symfony 4 Titouan GALOPIN Product Manager SymfonyInsight SfPot Décembre 2018 Deezer 1

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Ce talk est une analyse de mes expériences : c’est mon opinion ! Disclaimer 3

Slide 4

Slide 4 text

Client riche = logique métier côté client Introduction 4

Slide 5

Slide 5 text

En Web React, Vue, Angular, … Dialogue via HTTP avec une API Introduction 5

Slide 6

Slide 6 text

2. Mais au fait, pourquoi on développe des clients riches ? 6

Slide 7

Slide 7 text

Les utilisateurs ont développé de nouvelles attentes 7

Slide 8

Slide 8 text

- Chargement rapide 8

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

- 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

Slide 12

Slide 12 text

- 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

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Les clients riches sont utiles pour améliorer l’expérience utilisateur 14

Slide 15

Slide 15 text

Si développer un client riche n’améliore pas l’expérience utilisateur, cela n'apporte que des inconvénients 15

Slide 16

Slide 16 text

3. Quand les clients riches tournent mal 16

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Un SLA de 99.999% = 1 erreur sur 100 000 requêtes 19

Slide 20

Slide 20 text

Risques d’erreurs plus élevé => nécessité de mieux gérer les erreurs => complexité additionnelle 20

Slide 21

Slide 21 text

Le navigateur fait beaucoup de travail pour vous 21

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Se baser sur les navigateurs pour gérer l’historique, la session ou les cookies simplifie énormément votre code 23

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Le front-end est un autre métier 25

Slide 26

Slide 26 text

Combien de développeurs(ses) dans votre équipe maîtrisent parfaitement à la fois React et Symfony ? Tous ? La moitié ? Seulement quelque uns ? 26

Slide 27

Slide 27 text

Une application interactive implique une façon de développer différente => il faut des compétences spécifiques => complexité humaine additionnelle 27

Slide 28

Slide 28 text

Comment lutter contre ces nouvelles sources de complexité ? 28

Slide 29

Slide 29 text

Ne pas utiliser de client riche si cela n’améliore pas de manière significative l’expérience utilisateur 29

Slide 30

Slide 30 text

Savoir faire une balance entre expérience utilisateur et dette technique additionnelle 30

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

4. Un client riche dans Symfony 4 32

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Webpack Encore est absolument génial 34

Slide 35

Slide 35 text

35 {% block stylesheets %} {{ encore_entry_link_tags('user-registration') }} {% endblock %} {% block javascripts %} {{ encore_entry_script_tags('user-registration') }} {% endblock %} Twig + Vanilla JS

Slide 36

Slide 36 text

Hello world

// user-registration.js render(

Overriden!

, document.getElementById('react')); Twig + React React écrase le HTML original : progressive enhancement

Slide 37

Slide 37 text

37 {{ twig_data|json_encode }} Twig + React Pas nécessairement besoin d’API

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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)

Slide 41

Slide 41 text

41 Deux dossiers distincts ├── api │ ├── bin │ ├── config │ ├── public │ ├── src │ ├── var │ └── vendor └── client ├── node_modules ├── public └── src

Slide 42

Slide 42 text

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'); }

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Attention au SEO ! 45

Slide 46

Slide 46 text

Attention au SEO ! Aujourd’hui, la plupart des robots d’indexation comprennent bien les applications Javascript 46

Slide 47

Slide 47 text

Pour un site à fort trafic : Server-Side Rendering Sinon : pas forcément nécessaire 47

Slide 48

Slide 48 text

Limenius/ReactBundle pour le Server-Side Rendering 48

Slide 49

Slide 49 text

Conclusion 49

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Merci ! Questions ? Titouan GALOPIN Product Manager SymfonyInsight SfPot Décembre 2018 Deezer 52