DEV Community: Denis SOURON

Du pattern matching en JS ?

Denis SOURON — Thu, 09 Feb 2023 10:45:06 +0000

Non malheureusement ce n'est pas (encore) possible en Javascript, ni en Typescript. Mais on peut essayer de s'en rapprocher, notamment en séparant l'identification d'un scénario de son exécution. L'objectif est de renforcer la lisibilité et rapprocher le code du problème à résoudre. Pour illustrer le propos, nous utiliserons le traitement d'un article de blog (ajout, suppression, publication, etc.) à partir des informations contenues dans cet article. De plus, je vous propose d'y aller étape par étape afin que vous puissiez appliquer ce refactoring dans votre code.

NB: Les extraits de code présentés ci-dessous sont en Typescript et reposent sur la programmation fonctionnelle. Donc pas de classes et pas d'héritage, mais des data, des fonctions et aussi des fonctions de fonctions.

Définition d'un contexte de travail

Un peu de modélisation

Commençons par définir une interface qui représente la payload à traiter, dans le cas présent un article. Cet article possède plusieurs attributs qui indique s'il est à supprimer, à publier ou à créer.

// article.ts
export interface Article {
  delete: boolean;
  publishAction: PublishAction;
  id: string;
  content: string;
}

/**
 * Using Object instead of Enum here
 * @see https://www.typescriptlang.org/docs/handbook/enums.html#objects-vs-enums
 */
export const PUBLISH_ACTION = {
  none: 0,
  unpublish: 1,
  publish: 2,
} as const;

export type PublishAction = typeof PUBLISH_ACTION[keyof typeof PUBLISH_ACTION];

En complément, définissons deux interfaces pour améliorer le typage de notre exemple : un repository et un logger.

// dependencies.ts
export interface ArticleRepository {
  createOrUpdate: <T>(entity: T) => Promise<T>;
  delete: <T>(entity: T) => Promise<T>;
  publish: <T>(entity: T) => Promise<T>;
  unpublish: <T>(entity: T) => Promise<T>;
}

export interface Logger {
  debug: (...args: any[]) => void;
  info: (...args: any[]) => void;
  warn: (...args: any[]) => void;
  error: (...args: any[]) => void;
}

Une première version (très) procédurale

Je vous propose l'implémentation suivante pour le traitement d'un article comme base de réflexion.

// index.ts
import { Article, PUBLISH_ACTION } from "./article";
import { ArticleRepository, Logger } from "./dependencies";

type ProcessArticle = (dependencies: {
  articleRepository: ArticleRepository;
  logger: Logger;
}) => (parameters: { article: Article }) => Promise<unknown>;
export const processArticle: ProcessArticle =
  ({ articleRepository, logger }) =>
  ({ article }) => {
    if (article.delete) {
      logger.debug(`Delete article with id : ${article.id}`);
      return articleRepository
        .delete(article)
        .then(() =>
          logger.debug(`Successfully deleted article with id : ${article.id}`)
        )
        .catch((err) =>
          logger.warn(`Cannot delete article with id : ${article.id}`, err)
        );
    }

    if (article.publishAction === PUBLISH_ACTION.unpublish) {
      logger.debug(`Unpublish article with id : ${article.id}`);
      return articleRepository
        .unpublish(article)
        .then(() =>
          logger.debug(
            `Successfully unpublished article with id : ${article.id}`
          )
        )
        .catch((err) =>
          logger.warn(`Cannot unpublish article with id : ${article.id}`, err)
        );
    }

    if (article.publishAction === PUBLISH_ACTION.publish) {
      logger.debug(`Publish article with id : ${article.id}`);
      return articleRepository
        .publish(article)
        .then(() =>
          logger.debug(`Successfully published article with id : ${article.id}`)
        )
        .catch((err) =>
          logger.warn(`Cannot unpublish article with id : ${article.id}`, err)
        );
    }

    if (article.content) {
      logger.debug(`Create or update article with id : ${article.id}`);
      return articleRepository
        .createOrUpdate(article)
        .then(() =>
          logger.debug(
            `Successfully created or updated article with id : ${article.id}`
          )
        )
        .catch((err) =>
          logger.warn(
            `Cannot create or update article with id : ${article.id}`,
            err
          )
        );
    }

    throw new Error(
      `Unexpected value for article : ${JSON.stringify(article)}`
    );
  };

Avant de travailler sur la structure du code, parcourons ensemble le contenu de la fonction processArticle() afin de comprendre comment notre article est traité.

Pour commencer, on peut déjà écarter le logger dont le rôle est d'afficher en debug les différentes étapes et en warn les anomalies sur le traitement d'un article. Ensuite on remarque que la fonction gère 5 use-case distincts : suppression, dépublication, publication, création/mise à jour et un cas d'erreur. Cependant, même si on comprend le code écrit ligne par ligne, on peut identifier plusieurs problèmes majeurs : les éléments structurants sont noyés parmi le reste du code, la fonction réalise seule plusieurs actions, l'identification des scénarios est couplée à l'exécution de ces scénarios. Cette fonction a donc deux responsabilités (l'identification du scénario et les actions à réaliser) et viole le principe de responsabilité unique (SRP).

Si vous n'êtes pas convaincu que ce couplage est problématique, essayez de visualiser les impacts sur le code des besoins suivants :

"Bug : au moment de la publication les articles doivent avoir un contenu"
"Feature : Rendre impossible la suppression d'articles qui sont publiés"
"Feature : Permettre la création et la publication en une seule fois"

Sans refactoring, on voit que le code va vite devenir difficile à maintenir et il sera de plus en plus compliqué d'identifier l'intention derrière le code.

Petit détour par Clean Code

Afin de traiter certains des problèmes mentionnés précédemment, je vous propose d'utiliser une technique classique : la décomposition en plusieurs fonctions (Clean Code : "Extract till you drop").

import { Article, PUBLISH_ACTION } from "./article";
import { ArticleRepository, Logger } from "./dependencies";

type ProcessArticle = (dependencies: {
  articleRepository: ArticleRepository;
  logger: Logger;
}) => (parameters: { article: Article }) => Promise<unknown>;
export const processArticle: ProcessArticle =
  ({ articleRepository, logger }) =>
  ({ article }) => {
    if (article.delete) {
      return deleteArticle({ articleRepository, logger })({ article });
    }

    if (article.publishAction === PUBLISH_ACTION.unpublish) {
      return unpublishArticle({ articleRepository, logger })({ article });
    }

    if (article.publishAction === PUBLISH_ACTION.publish) {
      return publishArticle({ articleRepository, logger })({ article });
    }

    if (article.content) {
      return createOrUpdateArticle({ articleRepository, logger })({ article });
    }

    throw new Error(
      `Unexpected value for article : ${JSON.stringify(article)}`
    );
  };

type DeleteArticle = (dependencies: {
  articleRepository: ArticleRepository;
  logger: Logger;
}) => (parameters: { article: Article }) => Promise<unknown>;
export const deleteArticle: DeleteArticle =
  ({ articleRepository, logger }) =>
  ({ article }) => {
    logger.debug(`Delete article with id : ${article.id}`);

    return articleRepository
      .delete(article)
      .then(() =>
        logger.debug(`Successfully deleted article with id : ${article.id}`)
      )
      .catch((err) =>
        logger.warn(`Cannot delete article with id : ${article.id}`, err)
      );
  };

type UnpublishArticle = (dependencies: {
  articleRepository: ArticleRepository;
  logger: Logger;
}) => (parameters: { article: Article }) => Promise<unknown>;
export const unpublishArticle: UnpublishArticle =
  ({ articleRepository, logger }) =>
  ({ article }) => {
    logger.debug(`Unpublish article with id : ${article.id}`);

    return articleRepository
      .unpublish(article)
      .then(() =>
        logger.debug(`Successfully unpublished article with id : ${article.id}`)
      )
      .catch((err) =>
        logger.warn(`Cannot unpublish article with id : ${article.id}`, err)
      );
  };

type PublishArticle = (dependencies: {
  articleRepository: ArticleRepository;
  logger: Logger;
}) => (parameters: { article: Article }) => Promise<unknown>;
export const publishArticle: PublishArticle =
  ({ articleRepository, logger }) =>
  ({ article }) => {
    logger.debug(`Publish article with id : ${article.id}`);

    return articleRepository
      .publish(article)
      .then(() =>
        logger.debug(`Successfully published article with id : ${article.id}`)
      )
      .catch((err) =>
        logger.warn(`Cannot unpublish article with id : ${article.id}`, err)
      );
  };

type CreateOrUpdateArticle = (dependencies: {
  articleRepository: ArticleRepository;
  logger: Logger;
}) => (parameters: { article: Article }) => Promise<unknown>;
export const createOrUpdateArticle: CreateOrUpdateArticle =
  ({ articleRepository, logger }) =>
  ({ article }) => {
    logger.debug(`Create or update article with id : ${article.id}`);

    return articleRepository
      .createOrUpdate(article)
      .then(() =>
        logger.debug(
          `Successfully created or updated article with id : ${article.id}`
        )
      )
      .catch((err) =>
        logger.warn(
          `Cannot create or update article with id : ${article.id}`,
          err
        )
      );
  };

La première chose que l'on remarque, c'est que la lisibilité est bien meilleure. On a maintenant une base plus saine pour construire un pattern matching dans la fonction processArticle(). Cela va nous permettre d'isoler l'identification du scénario afin de pouvoir ajouter facilement des nouveaux use-case ou changer les conditions sans impacter le reste du traitement

Identifier précisément et explicitement le scénario

Explicit is better than implicit

Dans notre exemple nous avons 5 use-case distincts, donc faisons ressortir explicitement ces 5 scénarios. Pour ce faire, on peut baser sur un simple Enum comme ci-dessous.

// command.ts
export const COMMAND = {
  delete: 0,
  unpublish: 1,
  publish: 2,
  createOrUpdate: 3,
  unknown: 4,
} as const;

export type Command = typeof COMMAND[keyof typeof COMMAND];

Ensuite, nous pouvons implémenter une méthode dont le rôle est d'identifier une intention (nommée Command dans notre exemple) à partir des informations contenues dans l'article. Il nous suffit de reprendre l'articulation du code précédent et de renvoyer le bon use-case.

// command.ts
import { Article, PUBLISH_ACTION } from "./article";

type GetCommand = (parameters: { article: Article }) => Command;
export const getCommand: GetCommand = ({ article }) => {
  if (article.delete) {
    return COMMAND.delete;
  }

  if (article.publishAction === PUBLISH_ACTION.unpublish) {
    return COMMAND.unpublish;
  }

  if (article.publishAction === PUBLISH_ACTION.publish) {
    return COMMAND.publish;
  }

  if (article.content) {
    return COMMAND.createOrUpdate;
  }

  return COMMAND.unknown;
};

S'approcher du pattern matching

L'astuce principale est de mêler les concepts de literals et d'IIFE. On va utiliser un objet litéral comme structure de notre pattern matching. Les clés de l'objet correspondent aux différents use-case et les valeurs associées sont les implémentations de ces use-case.

const objectLiteral = {
  case1: () => fun1(),
  case2: () => fun2(),
  case3: () => fun3(),
};

A partir d'un objet litéral comme ci-dessus, l'objectif est de cibler le use-case et d'exécuter la bonne callback. Point important, on utilise des arrow functions pour éviter d'exécuter tous les scénarios à la création de l'objet.

const callback = objectLiteral["case1"];

callback(); // Will call fun1()

A l'étape précédente, nous avons défini une la fonction getCommand() dont le rôle est d'identifier le use-case. Ensuite, nous pouvons remplacer les clés de l'objet par des valeurs de Command. Et pour finir, on écrit les arrow functions à partir des fonctions existantes. Ce qui donne :

const objectLiteral = {
  [COMMAND.delete]: () =>
    deleteArticle({ articleRepository, logger })({ article }),
  [COMMAND.unpublish]: () =>
    unpublishArticle({ articleRepository, logger })({ article }),
  [COMMAND.publish]: () =>
    publishArticle({ articleRepository, logger })({ article }),
  [COMMAND.createOrUpdate]: () =>
    createOrUpdateArticle({ articleRepository, logger })({ article }),
  [COMMAND.unknown]: () => {
    throw new Error(
      `Unexpected value for article : ${JSON.stringify(article)}`
    );
  },
};

const callback = objectLiteral[getCommand({ article })];

callback();

Enfin si on reprend notre fonction initiale et que l'on retire les variables intermédiaires, on obtient la syntaxe ci-dessous qui représente l'objectif de cet article.

// article.ts
type ProcessArticle = (dependencies: {
  articleRepository: ArticleRepository;
  logger: Logger;
}) => (parameters: { article: Article }) => Promise<unknown>;
export const processArticle: ProcessArticle =
  ({ articleRepository, logger }) =>
  ({ article }) =>
    ({
      [COMMAND.delete]: () =>
        deleteArticle({ articleRepository, logger })({ article }),
      [COMMAND.unpublish]: () =>
        unpublishArticle({ articleRepository, logger })({ article }),
      [COMMAND.publish]: () =>
        publishArticle({ articleRepository, logger })({ article }),
      [COMMAND.createOrUpdate]: () =>
        createOrUpdateArticle({ articleRepository, logger })({ article }),
      [COMMAND.unknown]: () => {
        throw new Error(
          `Unexpected value for article : ${JSON.stringify(article)}`
        );
      },
    }[getCommand({ article })]());

Conclusion

On y est presque ! Malheureusement, on est contraint de passer par une structure intermédiaire (que j'ai appelé Command dans cet exemple) afin de construire notre pattern matching.

Que pensez-vous de cette syntaxe ? Est-ce que Javascript devrait inclure un vrai pattern matching, comme en C# par exemple ?

Exploiter les Discriminated Union en Typescript

Denis SOURON — Thu, 06 Oct 2022 12:26:46 +0000

De quoi parle-t-on ?

En Typescript, il est possible de définir des types de plusieurs manières : interface, classe, enum, mot-clé type, as const, etc. Dans cet article, nous allons nous concentrer sur les types construits à partir d'une union disjointe et les avantages d'une telle pratique. L'union en Typescript se fait via le symbole | (ex : type Union = A | B | C). Le terme disjoint n'est pas anodin car contrairement au polymorphisme, les types que l'on va utiliser peuvent ne rien avoir en commun.

Mise en situation

Prenons un exemple très simple, la représentation des utilisateurs dans une application. Ces utilisateurs peuvent être des invités (guest), des clients (customer) ou des administrateurs (admin). Les utilisateurs connectés ont un identifiant et les administrateurs ont des permissions spécifiques relatives à leur domaine d'administration. Construisons donc une interface User pour gérer nos utilisateurs.

interface User {
  userType: "Guest" | "Customer" | "Admin";
  login?: string;
  accessRights?: string[]; // could be more specific
}

Certaines propriétés sont optionnelles car elles n'existent pas pour l'utilisateur invité (et qu'on utilise le mode strict du compilateur Typescript).

Cette interface nous permet de créer des utilisateurs valides :

const johnDoe: User = {
  userType: "Admin",
  login: "JohnDoe",
  accessRights: ["database", "monitoring"],
};
const guest: User = {
  userType: "Guest",
};

Mais nous pouvons également créer des utilisateurs qui correspondent à des cas non souhaités :

const customerWithoutLogin: User = {
  userType: "Customer",
};
const guestWithAccessRights: User = {
  userType: "Guest",
  accessRights: ["fs"],
};

Et on ne peut pas garantir si par exemple l'identifiant existe ou pas :

johnDoe.login.toUpperCase(); // Object is possibly 'undefined'.
guest.login.toUpperCase(); // Object is possibly 'undefined'.
customerWithoutLogin.login.toUpperCase(); // Object is possibly 'undefined'.
guestWithAccessRights.login.toUpperCase(); // Object is possibly 'undefined'.

En général on finit par utiliser une condition ou du chainage optionnel, ce qui renforce l'incertitude sur le fonctionnement au runtime :

// Which one is really executed ?
johnDoe.login?.toUpperCase();
guest.login?.toUpperCase();
customerWithoutLogin.login?.toUpperCase();
guestWithAccessRights.login?.toUpperCase();

Pour réduire cette incertitude, il ne nous reste plus qu'à écrire des tests unitaires, faire du monitoring, du debug et lever des exceptions. Heureusement, nous pouvons éviter tout ça avec un meilleur typage.

Discriminated Union

Explicit is better than implicit

Nous avons trois types d'utilisateurs distincts et les regrouper dans une même interface/classe est une erreur commune. Et c'est normal, on nous répète souvent DRY (Don't Repeat Yourself) et on a envie de factoriser les utilisateurs dans une même classe ou dans une même interface pour y appliquer des méthodes communes.

Et si on faisait le contraire ? Trois types d'utilisateurs, donc trois interfaces.

interface GuestUser {
  userType: "Guest";
}

interface CustomerUser {
  userType: "Customer";
  login: string;
}

interface AdminUser {
  userType: "Admin";
  login: string;
  accessRights: string[];
}

Ensuite, il nous suffit de définir un type qui correspond à l'union des trois interfaces distinctes :

type User = GuestUser | CustomerUser | AdminUser;

Cette fois, la syntaxe nous permet toujours de créer des utilisateurs valides :

const johnDoe: User = {
  userType: "Admin",
  login: "JohnDoe",
  accessRights: ["database", "monitoring"],
};
const customer: User = {
  userType: "Customer",
  login: "JaneDoe",
};
const guest: User = {
  userType: "Guest",
};

Mais interdit la création d'utilisateurs qui n'ont pas de sens :

/**
 * Type '{ userType: "Customer"; }' is not assignable to type 'User'.
 * Property 'login' is missing in type '{ userType: "Customer"; }'
 * but required in type 'CustomerUser'.
 */
const customerWithoutLogin: User = {
  userType: "Customer",
};

/**
 * Type '{ userType: "Guest"; accessRights: string[]; }'is not assignable to type 'User'.
 * Object literal may only specify known properties,
 * and 'accessRights' does not exist in type 'GuestUser'.
 */
const guestWithAccessRights: User = {
  userType: "Guest",
  accessRights: ["fs"],
};

L'accès aux propriétés est également bien plus prédictible :

johnDoe.login.toUpperCase(); // OK
customer.login.toUpperCase(); // OK
guest.login.toUpperCase(); // Property 'login' does not exist on type 'GuestUser'.

L'inférence de type fait également des merveilles :

// login is defined because GuestUser is excluded (Type guard)
const displayLogin = (user: User) =>
  user.userType === "Guest" ? "Guest" : user.login;

ProTip : Si l'inférence ne fonctionne pas, pensez à définir un champ qui va aider Typescript à déterminer le bon type (userType dans notre exemple). Vous pouvez aussi identifier le type manuellement avec le mot-clé is.

const isAdmin = (user: User): user is AdminUser =>
  (user as AdminUser).accessRights !== undefined;

const users: User[] = [johnDoe, customer, guest];

users.filter(isAdmin).forEach((admin) => console.log(admin.accessRights));

Conclusion

Vous pouvez maintenant être plus précis sur le typage des données. Rien de révolutionnaire ici mais rappelez-vous que le typage est un bon moyen d'augmenter la prédictibilité de votre code.

Pour aller plus loin

Je vous invite à aller voir mon article sur le pattern matching en JS (qui arrive bientôt) qui complète assez bien les unions disjointes que l'on vient de voir. En combinant les deux, vous pouvez notamment faire une sorte de polymorphisme sans héritage et sans classe.

const redirectToHomePage = () => (location.href = "/");
const redirectToAccountPage = () => (location.href = "/account");
const redirectToAdminDashboardPage = () => (location.href = "/admin/dashboard");

export const redirectToUserPage = (user: User) =>
  ({
    Guest: () => redirectToHomePage(),
    Customer: () => redirectToAccountPage(),
    Admin: () => redirectToAdminDashboardPage(),
  }[user.userType]());

Un article également disponible sur :

le blog Younup : https://www.younup.fr/blog/exploiter-les-discriminated-unions-en-typescript
mon blog : https://brack0.dev/fr/blog/ts-discriminated-union

Deep dive Angular : Performance des templates

Denis SOURON — Thu, 14 Oct 2021 07:00:21 +0000

La performance est un sujet récurrent quand on parle de frontend. Les principaux acteurs (librairies/frameworks Javascript) y font tous référence dès la page d'accueil. Angular est connu pour intégrer un bundle plus complet mais plus lourd que ses concurrents directs. Même si ces différentes technologies n'embarquent pas les mêmes fonctionnalités, il reste une problématique à résoudre pour tous : le rendu HTML. Nous allons analyser ensemble le fonctionnement d'Angular dans trois cas précis : la gestion des blocs statiques, la mise à jour du DOM et la mise en cache de valeurs. Cet article se rapproche de ce qui a été fait par Grafikart en comparant Vue à React : https://grafikart.fr/tutoriels/vuejs-perf-react-1941. Certains exemples de code sont volontairement proches pour se donner des éléments de comparaison avec React et Vue.

Disclaimer : L'objectif de ce Deep dive est d'étudier la performance des templates Angular et de comparer leur fonctionnement avec ceux des concurrents directs. La performance d'un framework frontend ne peut et ne doit se résoudre à cette analyse. De même, elle ne peut s'en soustraire.

Précision technique : La notion de template en Angular peut faire référence à la partie d'un composant écrite en HTML, mais aussi à un <ng-template>. Ce double sens peut parfois rendre le propos confus. Si tel est le cas, vous pouvez bien évidemment m'en faire part directement, cela n'en sera que bénéfique pour les prochains lecteurs.

Les blocs statiques

Pour commencer, partons d'un simple template comme celui-ci et essayons de l'analyser :

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  template: `
    <h1>Hello world</h1>
    <div *ngIf="foo === 'bar'">Lorem ipsum dolor sit amet</div>
    <p>{{ value }}</p>
  `,
})
export class AppComponent {
  public foo = '';
  public value = 'Value';
}

Le code produit par la compilation Angular est un peu plus fourni. Voici la partie qui concerne AppComponent avec quelques ajustements pour la lisibilité (build en mode développement, renommage des imports webpack, suppression des symboles 'ɵ').

function AppComponent_div_2_Template(rf, ctx) { if (rf & 1) {
    angularCore["elementStart"](0, "div");
    angularCore["text"](1, "Lorem ipsum dolor sit amet");
    angularCore["elementEnd"]();
} }
class AppComponent {
    constructor() {
        this.foo = '';
        this.value = 'Value';
    }
}
AppComponent.fac = function AppComponent_Factory(t) { return new (t || AppComponent)(); };
AppComponent.cmp = /*@__PURE__*/ angularCore["defineComponent"]({ type: AppComponent, selectors: [["app-root"]], decls: 5, vars: 2, consts: [[4, "ngIf"]], template: function AppComponent_Template(rf, ctx) { if (rf & 1) {
        angularCore["elementStart"](0, "h1");
        angularCore["text"](1, "Hello world");
        angularCore["elementEnd"]();
        angularCore["template"](2, AppComponent_div_2_Template, 2, 0, "div", 0);
        angularCore["elementStart"](3, "p");
        angularCore["text"](4);
        angularCore["elementEnd"]();
    } if (rf & 2) {
        angularCore["advance"](2);
        angularCore["property"]("ngIf", ctx.foo === "bar");
        angularCore["advance"](2);
        angularCore["textInterpolate"](ctx.value);
    } }, directives: [angularCommon.NgIf], encapsulation: 2 });

Deux éléments importants sont à noter sur le code que l'on peut observer. Premièrement, on peut remarquer une fonction qui contient le contenu du *ngIf (cf. AppComponent_div_2_Template). Ce n'est pas surprenant, souvenez-vous que l'astérisque sur les directives est un sucre syntaxique pour un bloc avec <ng-template> (pour rappel https://angular.io/guide/structural-directives#structural-directive-shorthand). En fait, une fonction de rendu sera créée pour chaque <ng-template> dans notre application. Cela veut dire que le rendu est non seulement découpé au niveau des composants, mais également en fonction des <ng-template> présents dans l'application.

Pour le deuxième aspect qui nous intéresse, concentrons-nous sur une portion de code que l'on n'a assez peu l'occasion de voir quand on fait du développement web : (rf & 1) et (rf & 2). Oui il s'agit bien d'une opération bit à bit. Je vous rassure, nous n'entrerons pas dans les détails ici. Toutefois, selon vous, à quoi pourrait servir ces conditions dans les fonctions de rendu ? Regardons ensemble le code pour essayer d'en déduire les subtilités.

Dans la partie rf & 1, on peut identifier la création d'un <h1> avec son contenu "Hello world", puis un template et enfin un <p>. Ces éléments ressemblent beaucoup à ce qu'on a déclaré dans notre composant. Dans le deuxième bloc (rf & 2), si on met de côté l'instruction opaque "advance", il ne reste que le ngIf et l'interpolation {{ value }}.

Si maintenant je vous dis que la variable rf vient de RenderFlag, vous devriez avoir une bonne idée de ce qu'il se passe. En fait, en Angular les fonctions de rendu contiennent deux blocs d'instructions, un premier pour la création du template et le deuxième pour les mises à jour dudit template.

Que dire de tout ça ? Tout d'abord, on peut voir que les blocs statiques sont définis dans la partie création (cf. rf & 1 => Partie "création" de la fonction de rendu) et qu'ils ne sont pas modifiés lors des mises à jour du template (cf. rf & 2). C'est plutôt un bon point pour Angular, qui bénéficie comme VueJS d'une détection automatique des contenus statiques, contrairement à React qui requiert l'usage de React.memo() et d'un composant dédié. Demi-point bonus pour Angular par rapport à VueJS, les contenus statiques ne sont créés que s'ils sont visibles, là où en VueJS tous ces contenus sont générés dès la création du composant même s'ils sont masqués par un v-if. La seconde conclusion que l'on peut tirer concerne les rerendu ou plutôt l'absence de rerendu mais je vous propose de traiter ça plus en détails dans le chapitre suivant.

Les mises à jour de template

NB : Etant donné que les illustrations de code à partir de maintenant peuvent être conséquentes, un commit avec les composants et un extrait du build en mode développement sera fourni en guise d'exemple.

Avec un découpage des composants à partir des <ng-template>, Angular isole les problématiques de création et de mise à jour très finement. Si bien que les optimisations faites au niveau des composants sont aussi valables pour les templates. C'est notamment le cas de la différenciation entre les propriétés qui provoquent une mise à jour du template et celles qui sont externes. Ainsi, comme VueJS et React (via memo), Angular ne va pas faire de rendu (ou plutôt d'update si on se fie à l'analyse du chapitre précédent) pour les composants enfants dont les entrées n'ont pas été modifiées. Cependant, comme nous l'avons vu auparavant, Angular est également capable de limiter les mises à jour aux éléments pertinents parmi le template parent et chaque <ng-template>.

Pas vraiment convaincu par ces explications ? Vérifions ensemble avec un exemple :

Commençons par lancer l'application préparée pour l'occasion, puis saisissons 'compteur' dans le champ de recherche pour activer la condition du *ngIf.
Deux boutons s'affichent comme prévu : 'Incrémenter' et 'Ajouter un item'
En cliquant sur le bouton 'Incrémenter', on déclenche la fonction AppComponent_div_7_Template_button_click_3_listener() (d'après le fichier main.js reporté dans les assets)
Remarquer le contenu du *ngIf est dans la fonction AppComponent_div_7_Template() et que celui du *ngFor est dans AppComponent_tr_16_Template().

Voici ce que l'on obtient en regardant le Flamegraph associé à notre clic :

En y regardant de plus près, on peut effectivement distinguer les étapes dans le fonctionnement d'Angular (cycle de vie, étapes de rafraichissement, détections de différences, validations, etc). De plus, on retrouve des éléments connus comme la fonction AppComponent_div_7_Template_button_click_3_listener() associée au clic sur le bouton, mais aussi des fonctions de rendu comme AppComponent_Template() et AppComponent_div_7_Template(). Pourtant, il n'y a aucune trace de la fonction AppComponent_tr_16_Template(). Même en cherchant bien, il nous est impossible de trouver un appel de la fonction qui fait le rendu du contenu du *ngFor ! Ce qui veut dire que le contenu du *ngFor n'est pas impacté par les actions satellites. Pour être exact, la fonction AppComponent_tr_16_Template() ne s'est pas déclenchée car il y a eu un contrôle sur le tableau items qui est en paramètre du *ngFor. Dans notre cas, pas de changements sur items donc pas d'appel à la fonction. A l'inverse, la mutation, l'ajout ou la suppression d'éléments aurait provoqué un appel à AppComponent_tr_16_Template() et une mise à jour du template.

Donc ça voudrait dire qu'à chaque mise à jour des templates Angular va vérifier un par un chaque élément de chaque tableau pour détecter d'éventuels changements, ce n'est pas terrible pour les performances non ? Non effectivement et on peut le constater rapidement si on utilise beaucoup de *ngFor sans précaution. Mais rassurez-vous, je vous liste ci-dessous trois méthodes que vous connaissez peut-être déjà pour réduire efficacement les détections de changements sur les tableaux :

Utiliser la fonction trackBy pour simplifier les comparaisons entre les éléments
Isoler la boucle *ngFor dans un composant utilisant la stratégie OnPush avec le tableau en @Input(), seuls les changements de référence du tableau déclencheront un rendu par défaut (libre à vous ensuite de forcer d'autres rendus si besoin)
Sortir de zone.js quand vous risquez de provoquer beaucoup de mise à jour des templates sur une courte période (https://angular.io/api/core/NgZone#runOutsideAngular)

Avant de finir cette section sur ~~le rerendu~~ la mise à jour des templates Angular, vous pouvez retrouver ici un exemple qui met en avant la stratégie OnPush.

En analysant le comportement d'Angular, on constate que le Framework répond à la problématique initiale : éviter les rendus et les rafraichissements inutiles. Néanmoins, il est difficile de dire si la solution est plus efficace que celle proposée par React et VueJS. D'un côté, on a un découpage fin et beaucoup d'efforts sur la détection de changement ; de l'autre, un peu moins de vérifications et l'utilisation du VirtualDOM pour limiter les mises à jour du DOM. Quelques pistes de réponse sur ce fameux benchmark : https://krausest.github.io/js-framework-benchmark/index.html

Mise en cache des valeurs calculées dans les templates

Si vous avez déjà fait un peu d'Angular, vous savez que les optimisations que j'ai mentionnées précédemment ne s'applique pas dans un cas précis : les fonctions dans les templates. Qu'elles soient explicites (*ngIf="isValid()) ou implicites ({{ a * b + c }}), les fonctions peuvent également causer des problèmes de performance. A chaque raffraichissement de l'application, toutes les fonctions présentes dans les composants affichés sont réévaluées. Dans certains cas cela peut être désastreux. Imaginez un tableau de données avec 500 lignes et des colonnes contenant des dates (date de début, date de fin, date de sortie, date de création, etc). Les performances s'écroulent quand chaque évènement de scroll provoque un formatage de toutes les dates du tableau.

Vous pouvez constater par vous-même, en reprenant le code du chapitre précédent, que l'ajout d'un item dans le tableau provoque un recalcul de {{ count * 2 }} (constater l'appel à ɵɵtextInterpolate2, textBindingInternal, updateTextNode puis setValue dans le Flamegraph).

Alors comment faire pour traiter les besoins de valeurs calculées sans faire exploser les performances, le nombre d'attributs et le nombre de fonctions utilitaires dans nos composants ? La réponse d'Angular s'appelle un Pipe et se base sur deux concepts : les références (souvenez-vous, la stratégie OnPush aime bien ça également) et la mise en cache. En prenant le dernier commit qui nous intéresse, vous devriez maintenant constater que l'ajout d'un élément dans le tableau ne provoque plus de calcul de {{ count * 2 }}.

Ni Angular, ni React, ni VueJS ne se démarque sur cet aspect. Les trois Frameworks permettent d'utiliser des méthodes directement dans les templates, avec les défauts de performance mentionnés plus haut. De plus, chacun propose une solution de mise en cache des valeurs : Pipe pour Angular, useMemo() pour React et computed() pour VueJS

Angular est sous-estimé ?

Résumons. Angular est capable d'isoler les contenus statiques pour éviter de les regénérer. De plus, au lieu de regénérer des morceaux plus ou moins conséquents en utilisant un Virtual DOM, il va analyser finement les templates à mettre à jour. Même si les méthodes diffèrent, l'objectif est identique : limiter les modifications du DOM au strict minimum car elles peuvent s'avérer couteuses. Enfin, pour la gestion des valeurs calculées, tout le monde est à la même enseigne en proposant une méthode directe mais peu performante et une méthode optimisée avec de la mise en cache.

Quelle surprise de découvrir qu'Angular soit aussi pointu et précis sur la gestion des templates. Pour être honnête, je m'attendais à avoir un système complexe et lourd. Même si cela ne fait pas d'Angular le meilleur Framework car il a toujours ses défauts et il ne convient pas à tous, le cœur du Framework, à savoir le rendu d'élément HTML, a des atouts face aux stars du moment, React et VueJS. De quoi peut-être vous (re)donner envie de l'utiliser ?

Un article également disponible sur :

le blog Younup : https://www.younup.fr/blog/deep-dive-angular-performance-des-templates
mon blog : https://brack0.dev/fr/blog/angular-template-performance

Cover by Yannes Kiefer on Unsplash