Suite à l'article de janvier, voici la suite avec pour toile de fond l'évolution de Driveo l'application SaaS de gestion d'auto école.

Les limites du code splitting

Malgré les analyses poussées que peuvent fournir les outils de GWT (SOYC - Story Of Your Compile), on arrive rapidement à la limite de l'exercice du fait que l'application n'a pas été structuré dès le début pour être chargeable bloc à bloc en fonction des besoins de l'utilisateur.

Le principe est de découper le menu en plusieurs sous-menus. Chaque sous-menu regroupe les appels aux fonctionnalités propre à une habilitation. Chaque sous-menu doit gérer le cycle de vie des gestion des écrans/objets propres à son habilitation.Ensuite, en fonction des habilitations, le menu père va charger en asynchrone les différents sous-menus. Les points de séparation (split) se feront à ce niveau. Chaque écran étant indépendant et n'interagissant qu'avec le bus événementiel, la premier javascript (le .cache.html) devrait être de taille très raisonnable.

Pour cela, j'ai du refactorer (réécrire une partie du code) le menu de Driveo. De plus, afin de gérer les changements d'écran de la manière le plus souple possible, il m'a semblé nécessaire de le gérer de manière événementiel. Pour cela GWT possède une fonction native : la gestion de l'historique.

La gestion de l'historique

Si on écoute les présentations et qu'on lit les docs des gars de l'équipe GWT de Google : on DOIT commencer par la mise au point de la gestion de l'historique quand on conçoit une application basée sur GWT.

Comme ce n'est pas très funky et que pas grand chose n'est visible pour les clients, je ne l'ai fait que 1 an et demi après...

La chose est relativement aisée et c'est bien documenté : Large scale application development and MVP. Le code source de l'exemple est même disponible. L'exemple comprend une utilisation de la gestion de l'historique avec GWT.

Le principe est que chaque élément des sous-menus est une ancre (Anchor). Quand on clique sur cette ancre, l'URL est modifié (un #NomMenu est rajouté à la fin) et un événement javascript de type historique est créé. Il suffit alors de réceptionner et de filtrer ces évènements dans les sous-menus pour gérer le cycle de vie de l'écran (l'afficher, le cacher, le détruire, le re-créer).

Cependant, il faut bien tester la chose et bien vérifier le comportement de l'application au démarrage quand l'utilisateur démarre directement sur un lien marqué par un historique (avec le #NomMenu à la fin). En effet, le marque page de l'utilisateur a de fortes chances d'en avoir un et il faut bien rediriger l'utilisateur vers le bon écran et réémettant un évènement javascript d'historique.

L'effet sur Driveo

Si vous regardez la courbe suivante, l'ajout de code splitting sans restructurer la partie menu n'a tenu qu'un temps. L'ajout d'une fonction transverse à tous les écrans (la gestion multi-agence) a rajouté 200ko sur le premier fichier javascript GWT à charger par le navigateur.

La mise à jour du menu, lui à permis de descendre très fortement la taille du javascript initial (à 270ko - dans la courbe il y aussi le CSS et les images) et surtout de le stabiliser malgré l'ajout de fonctionnalités.