#lazy_builder (à ne pas confondre avec lazy load) dans Drupal 8/9

En continuant à étudier Drupal, nous sommes tombés sur une technologie très intéressante qui y est intégrée. Et qui, à notre avis, est utilisée de manière déraisonnable. Et en vain. Parce que l'approche utilisée par cette technologie permet de donner instantanément une page très chargée (ou juste une page longue) à un utilisateur, puis de lui «donner» des données qui prennent beaucoup de temps à se former. Et en étudiant cette technologie, nous avons été confrontés au fait qu'il n'y a pas une seule explication simple de ce que c'est et comment la démarrer. Non, il y a des explications. Il n'y en a pas de simples. Maintenant, nous allons essayer de compenser ce problème.

description générale

Nous avons donc une page qui, pour une raison quelconque, prend beaucoup de temps à faire partie des données. Les raisons peuvent être différentes - une grande quantité de calculs, une grande quantité de données, de longues requêtes vers une base de données lente ou, en général, vous devez vous rendre à un service tiers à partir duquel obtenir des informations, que vous devez ensuite traiter. Les raisons ne sont pas importantes. Il est important que notre page contienne des données que nous pouvons envoyer tout de suite - en-têtes, pieds de page, quelques images, un tas de cadrages, du texte, de la publicité, à la fin. Et il y a des données que nous devons «obtenir», et cela prendra un certain temps.



Alors c'est tout. Habituellement, cette tâche est résolue par le mécanisme de "chargement paresseux" - une version allégée de la page est chargée, puis le script de chargement paresseux est déclenché, qui, en utilisant JavaScript, va au backend, prend les données à partir de là et les met aux bons endroits. Mais le chargement paresseux a une tonne d'inconvénients. En commençant par le fait que si, par exemple, nos données ne sont données qu'à un utilisateur autorisé, nous devons en outre autoriser ce script paresseux. Nous avons également toujours besoin d'activer JavaScript. Ce "truc paresseux" n'est pas très bon pour les robots d'exploration. Etc.



Et il s'avère que les créateurs de Drupal sont formidables. Et ils nous offrent un autre mécanisme, qui est dépourvu de presque tous les inconvénients du chargement paresseux. Et ce mécanisme est appelé "constructeur paresseux" - constructeur paresseux. Cela fonctionne comme tout ce qui est ingénieux - très simple.

À la place dans le twig-template où nous devons afficher des données "lourdes", nous mettons une variable ordinaire (presque), d'une manière tout à fait normale, comme ceci: {{lazy_data}}. Mais dans le préprocesseur dans lequel nous préparons cette variable, nous devons lui dire des mots magiques pour qu'elle devienne un constructeur paresseux. Cela ressemble à ceci:

$variables['lazy_data'] = [
  '#create_placeholder' => TRUE, // -  ,  Drupal   .
  '#lazy_builder' => [ // -     , -   .
    //...    
    ],
  ],
];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Et maintenant, Drupal, lorsqu'il rendra la page, remplacera cette variable par un espace réservé JavaScript, et les données elles-mêmes ne seront pas générées au moment du rendu. Autrement dit, cette page sera formée rapidement et sera fournie à l'utilisateur tout aussi rapidement. Et alors seulement, quand il est affiché par le navigateur sur l'écran, cet espace réservé se déclenchera, qui montera au backend et lui dira - "Je suis prêt, envoyez les données." Le backend se formera calmement et donnera ces données. Et ils seront insérés là où ils devraient être.



C'est tout! Et aucune autorisation supplémentaire n'est nécessaire - cela a déjà été fait sur le backend. Et vous n'avez pas besoin d'inclure de scripts supplémentaires - Drupal s'occupe de tout. Et aucune API de point d'entrée supplémentaire n'est nécessaire qui doit être écrite et maintenue en plus. Il n'est pas nécessaire de clarifier le type de données dont vous avez besoin - tout cela a déjà été fait sur le backend. Nous venons de remettre un morceau de "création de page" pour plus tard. C'est tout ce que nous avons fait.



Et le plus ingénieux ici est que si l'utilisateur n'a pas activé JavaScript, Drupal lui-même le reconnaît et forme immédiatement ces données lourdes, sans utiliser d'espace réservé. Autrement dit, comme s'il n'y avait pas de mécanisme de construction différée. Les robots des moteurs de recherche seront heureux de ne pas avoir à gérer des charges paresseuses auto-écrites, ils obtiendront une page régulière. Mais attendre quelques secondes, cette page n'est pas aussi critique pour eux que pour une personne.

Et maintenant, quelques détails techniques de la façon dont tout cela mouche faire

Répétons - dans le twig-template que nous écrivons comme d'habitude - nous mettons simplement la variable à l'endroit dont nous avons besoin. Et voilà, vous n'avez plus besoin de faire de gestes.

Dans le modèle de préprocesseur, dans lequel nous devons former cette variable, nous écrivons des "mots magiques" pour qu'il devienne "paresseux" et écrivons ce qu'il devrait appeler pour rendre paresseux notre variable:

$variables['lazy_data'] = [
  '#create_placeholder' => TRUE, // -  ,  Drupal   .
  '#lazy_builder' => [ // -   , -   .
    '_.lazy_renderer:renderBigData', [ // -   ,   . ,    .
      'info' => ' ', // -   ,     . . 
      'params' => ['foo' => 'boo'],
        'something_else' => 11
    ],
  ],
];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Nous devons maintenant créer un "service" Drupal qui sera engagé dans la formation de nos big data. Pour ce faire, dans le fichier nom_module.service.yml, qui se trouve à la racine du module requis (pas forcément auto-écrit), il faut déclarer ce service (nom_module.lazy_renderer), qui sera appelé pour former ce qui doit être envoyé à la variable 'lazy_data', qui puis il ira à ce talon , à la maison que Jack a construite .



Dans ce service, nous créons la fonction renderBigData, qui sera appelée. Et cette fonction devrait renvoyer un lien vers le modèle, qui sera rendu et inséré au bon endroit sur la page , dans la maison que Jack a construite .



Mais vous voulez passer quelque chose à cette fonction, non? Voici comment procéder.



Tout d'abord, nous vous rappelons que pour vendre quelque chose d'inutile, vous devez d'abord acheter quelque chose d'inutile, et afin d'utiliser un modèle pour le rendu, vous devez d'abord le déclarer. Autrement dit, dans le fichier nom_module.module, dans la fonction fonction promotion_theme (...), vous devez renvoyer, avec le reste des modèles, le modèle pour le nouveau modèle:

'my_template_for_lazy_building' => [
  'variables' => [
    'info' => '',
    'params' => [],
    'something_else' => 1
  ],
],
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Et puis tout est simple - dans le service, dans la fonction, tout ce qui est nécessaire est préparé, et ce modèle fraîchement déclaré est renvoyé au rendu, en lui transmettant ce que vous devez y transférer.



Et ce modèle, à son tour, a son propre préprocesseur, qui sera déclenché lorsque Drupal essaiera de rendre le modèle. À ce stade, le préprocesseur recevra les variables déclarées et transmises.



Autrement dit, techniquement, cela ressemble à ceci:

//        :
// '_.lazy_renderer:renderBigData'
//   :

class lazy_renderer {
        public function renderBigData($info, $params, $something_else) {
        //    
    //-  ,  .
    return [
        '#theme' => 'my_template_for_lazy_building',
      '#info' => $info,
      '#params' => $params,
      '#something_else' => $something_else
    ];
  }
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Le modèle de brindille lui-même doit être dans le répertoire des modèles du module, bien sûr.



C'est tout.



Et encore une fois, pour résumer "qui se tenait sur qui":

• Nous avons une variable lazy_data. Nous l'avons mis dans le twig-template d'une page comme une simple variable.
• Nous le créons dans le préprocesseur. Et nous lui disons qu'elle est "paresseuse" et qu'elle doit appeler le service ('module_name.lazy_renderer: renderBigData'), qui retournera le template (un autre, 'my_template_for_lazy_building') à rendre. Ce modèle sera rendu et inséré à la place des «données paresseuses».
• N'oubliez pas de déclarer notre modèle.

Nous espérons que nous avons pu vous parler de la technologie Lazy Builder de manière simple, mais en même temps aussi détaillée que possible.



Merci pour l'attention.