JavaScript. Comment créer une grille de données multithread incroyablement rapide pour les lignes. Partie : Les nuances du travail avec DOM

Démo | GitHub

Figure 1. Grille de données avec 1 000 000 de lignes

Fonctionnalités de la grille de données rapide :

• Incroyablement rapide
• Multithread
• Seulement 523 lignes de code
• Aucune dépendance
• JavaScript Vanille

Essayez de faire défiler et de rechercher 1 000 000 de lignes – Fast Data Grid.

Dans cet article, j'énumérerai les nuances du travail avec DOM. À propos du multithreading dans le prochain article.

Plus le DOM est petit, mieux c'est. Changer le contenu d'un DIV est plus rapide que de supprimer un DIV et d'en créer un nouveau.

Le navigateur est lent à restituer une grande arborescence DOM. Le navigateur ne restituera pas du tout 1 000 000 de lignes d'une hauteur de 20 px - la hauteur maximale d'un DIV dans Chrome est de 15 000 000 px. Moins il y a d'éléments HTML, mieux c'est.

Fast Data Grid ajoute autant de lignes au DOM que l'écran peut en contenir.

const rowsCount = Math.ceil(viewPortHeight / rowHeight);

Liste 1. Compter le nombre de lignes qui tiennent sur l'écran

Lorsque de nouvelles données doivent être générées, les DIV de ligne sont réutilisées. Les nouvelles données sont écrites dans les mêmes DIV. Changer le contenu d'un DIV est plus rapide que de supprimer un DIV et d'en créer un nouveau.

Lors du défilement, la position des lignes DIV est calculée à l'aide de JavaScript.

La hauteur maximale du DIV est de 15 000 000 px

Pour faire fonctionner le défilement, Fast Data Grid crée un gros DIV. L'événement scroll est attaché à ce DIV. Le gestionnaire d'événements de défilement calcule la position des DIV de ligne.

Figure 2. Grand DIV pour le défilement

Si la hauteur totale des lignes est supérieure à 15 000 000 px, alors les DIV de ligne doivent défiler plus rapidement que le grand DIV. Lorsque le grand DIV défile jusqu'à la fin -> les DIV de ligne doivent également défiler jusqu'à la fin.

Lors du défilement des lignes DIV, un coefficient doit être appliqué.

const scrollYKoef =
    // if {allRowsHeight} > 15 million -> we have to applay koef on scroll
    // if {allRowsHeight} <= 15 million -> {scrollYKoef} = 1
    (allRowsHeight - viewPortHeight) / (scrolHeight - viewPortHeight);


listen(scrollOverlayDiv, 'scroll', /** @param {Event & {target:HTMLDivElement}} evt */ evt => {
    const scrollTop = evt.target.scrollTop * scrollYKoef;
    rowsDiv.style.transform = `translateY(${scrollTop}px)`;
});

Listing 2. Utilisation du coefficient lors du défilement

La traduction de la transformation CSS est plus rapide que CSS top

Lors du défilement, la position est définie via la transformation et la traduction. La traduction de la transformation CSS est plus rapide que CSS top.

<!-- transform faster-->
<div>

<p><br>
<em>Listing 3. CSS transform translate is faster than CSS top</em></p>
<h2>
  
  
  Read DOM first, then modify DOM. It's bad to read DOM after modification
</h2>

<p>The browser displays frames on the monitor like this:<br>
First, JavaScript is processed, then styles are calculated, then layout, then rendering.</p>

<p><img src="https://img.php.cn/upload/article/000/000/000/173464994174788.jpg" alt="JavaScript. How to Make a Blazingly Fast Multithreaded Data Grid for  Rows. Part : The Nuances of Working with DOM" /><em>Figure 3. Standard order of operations when outputting a frame to the monitor</em></p>

<p>If the standard order is not violated, the browser will render the frame as quickly as possible.</p>

<p>At the beginning of the cycle, the DOM parameters are already calculated and correspond to the parameters of the previous frame. For example, box.offsetHeight is already calculated at the beginning of the cycle. But if you change the DOM and then read the DOM -> the browser will have to break the standard order. It will be necessary to calculate the layout again.<br>


<pre class="brush:php;toolbar:false">box.classList.add('super-big');

// Gets the height of the box in pixels and logs it out:
console.log(box.offsetHeight);

Listing 4. Modifier le DOM avant de lire le DOM. Mauvais. Conduit à une raclée de mise en page.

Un recalcul excessif de la mise en page est appelé « trashing de la mise en page ».

Une démonstration visuelle de la façon dont la modification du DOM avant la lecture ralentit le navigateur :
https://wilsonpage.github.io/fastdom/examples/animation.html

Excellent article sur le sujet :
Évitez les mises en page volumineuses et complexes et les mises en page | Articles | web.dev.

Auto-promotion

Je crée l'éditeur d'organigrammes le plus pratique DGRM.net.
C'est également le service le plus pratique pour les entreprises : les diagrammes de processus métier Excel.

Donnez des étoiles sur GitHub.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!