Développement d’application web. L’approche composant et l’approche modulaire (2/2)

Dans le billet précédent, on a vu en quoi consiste l’approche « composant » lors de la création d’une application.

Développement d’application web. L’approche composant et l’approche modulaire (1/2)

Celle-ci est largement inspirée de mon expérience avec Flex.

Vous pouvez donc réaliser votre application avec cette approche en deux étapes:

  • Ajouter les composants à votre application et les disposer dans l’interface
  • Faire communiquer les composants entre eux avec des classes liantes qui sont souvent vos classes « métier »

Lorsque l’on évoque le développement d’applications « entreprise », on évoque souvent une approche dite « modulaire ». Celle-ci est finalement assez proche de ce que l’on a vu avec nos composants, à queqlues nuances près.

L’approche « modulaire »

Dans le cas de « grosses » applications, vous allez vite vous retrouver avec des dizaines (voire centaines) de composants dans votre application. Vous allez devoir découper cela pour que cela ne devienne pas trop difficile à gérer. Le plus simple étant d’isoler de grands blocs indépendants. Il est assez rare que vous ayez besoin de toute votre application en permanence.

Une approche modulaire consiste principalement à charger / décharger des ensembles de composants. Le chargement / déchargement de ces « modules » vont aussi venir modifier le comportement de votre application de manière dynamique. C’est bien dynamique le mot-clé, puisque le chargement/déchargement se fait à la volée, souvent suite à une action utilisateur. L’exemple typique est une interface web avec une barre d’onglets. Chaque appui sur un onglet va venir ouvrir une partie d’une interface indépendante. Au lieu de charger toutes ces parties de manière statique au chargement de l’application, on va se contenter de charger le premier onglet lors du premier chargement. Lorsque l’utilisateur clique sur un autre onglet, on va charger le contenu correspondant de manière dynamique et l’afficher à l’écran.

Une approche modulaire a plusieurs avantages évidents:

  • Le premier chargement de l’application est plus court, car on a moins de choses à afficher + téléchargement initial réduit
  • Le téléchargement d’un module lourd peut être anticipé et réalisé en fond. Un exemple, dans Google Maps, lorsque vous survolez le bouton d’impression, Google va pré-charger l’interface d’impression de la carte de manière dynamique. Tant que vous n’avez pas réalisé cette action, ce module ne fait pas partie de la page.
  • En théorie, chaque module devrait même entre complètement indépendant de l’application dans laquelle il est chargé, afin d’être chargé dans une autre application sans problème. Il vous faudra voir si cet objectif est vraiment utile dans votre cas, car c’est souvent un objectif difficile à atteindre et cela rend le code bien plus complexe.

Le cas des « Single Page Web App »

Vous avez sûrement déjà entendu parler des « Single Page Web App » (abrégé SPA apparemment). C’est un peu le terme à la mode en ce moment qui désigne une application web (typiquement, un ensemble de pages) qui s’exécute au sein d’une même page. Les éléments de la page vont donc être chargés de manière dynamiques, à la demande. Cela ne vous rappelle rien :) ? Au passage, notez qu’on nous prend pour des guignols en nous vendant une 3/4ème fois les célèbres applications « Ajax » ou « Web 2.0 ». Le nom change mais le principe reste le même.

Un bon exemple de SPA est twitter.com. Lorsque vous naviguez sur twitter.com, en passant de l’accueil à la partie Connecter par exemple, vous allez rester sur la même page. L’URL va changer pour que vous puissiez la mettre dans vos bookmarks ou l’envoyer à quelqu’un. Seule le contenu de la partie centrale de la page a été modifié et remplacé.
Un autre bon exemple est l’application trello.com dont on vous explique même la technique:

 The Trello Tech Stack

Le cas du templating HTML / JavaScript

Il y a un autre terme assez populaire en ce moment, c’est celui de « templating ». Un template, c’est quoi? C’est un bout de code HTML contenant des « placeholders », c’est à dire des morceaux spécifiques qui sont identifiés de manière unique. En gros, c’est un DOM avec des variables à l’intérieur et parfois quelques opérations simples (if / for).

Par exemple:

<div class="entry">
  <h1>{{title}}</h1>
  <div class="body">
    {{body}}
  </div>
</div>

Tout seul, un template HTML ne sert pas à grand chose. Vous devrez lui injecter un objet au format JSON en entrée, provenant le plus souvent de votre serveur. Le mécanisme de templating va réaliser une « compilation » du template et de l’objet JSON pour créer au final un contenu HTML dans lequel les variables ont été remplacées par les propriétés de votre objet JSON. Ce contenu HTML sera ensuite ajouté dans le DOM de votre application.

L’avantage ici est de pouvoir pré-compiler un template pour le réutiliser ensuite. Seul le contenu JSON en entrée (dynamique car venu de votre serveur) change.

Par exemple, vous avez une liste de tweets à afficher à l’écran. Le serveur va vous fournir le contenu de ces tweets au format JSON. Du côté de votre page, vous avez votre template (avec une étape de pré-compilation pour de meilleures performances). Au moment où vous allez recevoir le JSON de votre serveur, il vous suffit de boucler sur toutes les entrées JSON et de les injecter dans votre template puis de récupérer le HTML résultat et de l’insérer dans votre page.

Le templating se rapproche plus de ce que l’on a vu avec les composants même s’il est assez hybride car il y a de nombreuses manières de l’utiliser:

  • Chargement à la volée ou pas des templates dans la page
  • Possibilité de réaliser la même opération (compilation d’un template avec du contenu JSON) côté serveur et de renvoyer le HTML résultant pour les opérations lourdes, qui donneraient du mal à l’exécution JavaScript. Apparemment, c’est une technique utilisée dans GMail avec une compilation serveur GWT. Idem dans Google+ le système de template Google Closure Templates peut être exécuté côté serveur et côté client

Conclusion

Voilà, un article assez long, j’espère que vous avez apprécié. Les développeurs Flex devraient être en terrain connu sur ces notions de composants et de module. Pour ce qui est du développement web, on sent qu’il y a l’envie mais ces concepts ne sont pas implémentés de manière « native » dans la spécification HTML. On a donc des solutions de remplacement comme le templating HTML/JS qui deviennent peu à peu standard « de facto » avec la notation de Mustache.

Ce qu’il aurait fallu, c’est que cette spécification soit intégrée à HTML dès le premier jour:

Web Components Explained

C’est un « Extremely early draft » mais il est prometteur. Pouvoir nommer des composants et les utiliser directement par leur nom de tag dans la page serait exactement ce qu’il faudrait. Entre temps, il va falloir faire avec une solution hybride, comprenant du templating.

Pour l’instant, je n’ai pas de « bonne » solution pour implémenter ces approches dans le monde HTML mais ce blog va me permettre d’expérimenter!

4 réflexions au sujet de « Développement d’application web. L’approche composant et l’approche modulaire (2/2) »

  1. Mickael

    Article intéressant, j’attends maintenant un petit exemple de code pour tout ça! :)
    Je suis moi même en train de regarder de plus près l’approche modulaire et les mécanismes de templatings JS. Je teste en ce moment l’utilisation de Backbone avec RequireJS et je trouve cette solution plutôt sympa. Notamment, grâce à require, lorsque tu définis ta vue Backbone, tu peux lui charger le template associé, ça évite d’avoir tous ses templates dans le index.html.
    La solution JQuery + Underscore + Backbone + Require me semble vraiment intéressante en tout cas.

    Par contre, sauf si j’ai raté un truc, soit tu utilises le templating JS, soit tu utilises tes templates Play, non ?

    Répondre
    1. admin Auteur de l’article

      Oui, il n’y a pas vraiment de lien entre les deux, pour l’instant je vais voir si j’ai besoin des templates côté client en fait. Encore pas mal d’expérimentations à faire !

      Fabien

      Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *