Hier erklärt Atif Afzal, wie man ein <div> verwendet, das dauerhaft auf der Seite vorhanden ist, wo Anheftwerkzeuge hinzugefügt/entfernt werden, und wie diese im Vergleich zum direkten Einfügen derselben Anheftwerkzeuge in den <body> weitaus besser funktionieren. Es wird nicht wirklich diskutiert, aber der Grund, warum man sie so hoch im DOM platziert, ist, dass man sie exakt dort absolut positionieren kann, wo man sie auf der Seite haben möchte, ohne sich mit verstecktem Überlauf oder relativen Eltern und dergleichen auseinandersetzen zu müssen.
Zu meiner Überraschung behoben allein das Vorhandensein eines separaten Containers, ohne auch nur die [CSS]-Eigenschaft
containhinzuzufügen, die Leistung. Das Hauptproblem war nun, es zu erklären. Zuerst dachte ich, dies könnte eine interne Browser-Heuristik sein, die dasRecalculate Styleoptimiert, aber es gibt keine Magie, und ich entdeckte den Grund.
Der Trick ist, erzwungene Neuberechnungen des Stils zu vermeiden
[…] Der Anheftwerkzeug-Container ist auf der Seite nicht sichtbar, daher macht die Änderung keine ungültige komplette Seiten-Render-Struktur. Hätte der Anheftwerkzeug-Container auf der Seite sichtbar sein sollen, dann wäre die komplette Render-Struktur ungültig geworden, aber in diesem Fall wurde nur ein unabhängiger Teilbaum ungültig gemacht.
Recalculating Stylefür einen kleinen Teilbaum von 3 nimmt nicht viel Zeit in Anspruch und ist daher schneller.
Sieht so aus, als ob hier popper.js verwendet wurde, also muss man schlau sein. Wir verwenden Toast-Nachrichten auf CodePen, und es ist die einzige Drittanbieter-Komponente, die wir derzeit verwenden: react-hot-toast. Ich habe es überprüft, und wir verstauen die Nachrichten nicht nur in einem eigenen <div>, sondern die Bibliothek selbst tut dies ebenfalls, also denke ich, wir sind im klaren.
Ich füge meine Anheftwerkzeuge normalerweise zum Body hinzu, daher ist es wirklich hilfreich zu wissen. Danke für den aufschlussreichen Artikel. Atifs Beitrag war auch großartig.
In Bezug auf Hot Toast, was war bisher Ihre Begründung dafür, diese Drittanbieter-Lösung beizubehalten, anstatt benutzerdefinierte, Promise-basierte Anheftwerkzeuge zu entwickeln, wenn Sie sie intern benötigen?
Wir könnten sie irgendwann ersetzen, es ist einfach schneller, Drittanbieter-Sachen zu verwenden, und in diesem Fall hat es alle Kriterien erfüllt, die wir brauchten.