‘none’ oder neu rendern / Sudo Null IT News

Eine kleine Fallstudie wurde durch den Artikel inspiriert https://itnext.io/using-css-to-speed-up-your-react-apps-a26470829472und zwar die folgende Passage (meine Übersetzung):

Verstecken statt aussteigen

Stellen Sie sich vor, Sie haben 2 Registerkarten. Wenn Sie mit den Standard-React-Methoden zwischen ihnen wechseln, werden „Tab from“ und „Tab to“ ausgehängt. …ein Beispiel aus Twitter…

Die Antwort liegt in der React-Laufzeit. Jedes Mal, wenn eine neue Komponente gemountet wird, muss React ein virtuelles DOM erstellen (eine verknüpfte Liste aller Unterkomponenten innerhalb des gemounteten Baums), die gesamte Logik in jeder der Komponenten (oder veralteten componentWillMount ) ausführen und dann die Komponenten zum DOM hinzufügen. Gleichzeitig muss React die vorherige Komponente unmounten, was bedeutet, dass das virtuelle DOM reduziert wird, componentWillUnmount ausführen und dann die entsprechenden Elemente aus dem DOM entfernen.

Es mag überraschen, aber das Aushängen ist keine billige Operation. Sie könnten denken, dass dies nur eine Entfernung ist, aber React muss Refs aus vielen Teilen des virtuellen DOM entfernen und die Lebenszyklen aller Komponenten ausführen, die ausgehängt werden. Dies kann nicht schnell passieren. Bis zu den Tagen von React Fiber (vor React 15.xx) war das Unmounten der vorherigen und das Mounten der nächsten Komponente sequentiell. Heute erledigt React dies parallel, um Zeit zu sparen, da diese Prozesse unabhängig voneinander sind.

Der Trick besteht nicht darin, React zum Mounten/Unmounten zu zwingen, sondern CSS zu verwenden, um den Inhalt der Tabs anzuzeigen/auszublenden.

Dann ging es um das gleiche Beispiel von Twitter und die Tatsache, dass bei diesem Entwicklungsansatz der DOM-Baum zu stark wachsen kann. Als Entwickler einer Anwendung, die möglicherweise viele Komponenten und eine große Anzahl von Registerkarten generieren kann (und die Person, die die Aufgabe hatte, herauszufinden, ob dies eine gute Optimierung wäre))) – habe ich mich entschieden, einen einfachen Code zu schreiben Testen Sie diese Theorie und dementsprechend die Konsequenzen:

importiere ‘./app.css’; uniqid aus ‘uniqid’ importieren; React,{useState} aus ‘react’ importieren; Funktion App() { const [tab, setTab] = useState(true) const Row = (Menge, bColor) => { const result = []
for (lass i =0; i< Menge; i+=1){ result. push(

Zeile {i} Tab {tab?1:2}

) } Ergebnis zurückgeben }; const handleClick = () => { console.log(tab) setTab(tabState=>!tabState) } return (

{ /* {

    {tab && Row(50000, ‘tomato’)} */} {

      {Row(50000, ‘tomato ‘) ‘)}

    } {/* {

      {!tab && Row(50000, ‘green’)} */} {

        {Zeile(50000, ‘grün’)}

      }

); } Standard-App exportieren;

Die einzige Bibliothek, die nach CRA und weiterer Bereinigung installiert wurde, ist uniqueId (für zusätzlichen Arbeitsaufwand und zusätzliche Demonstration der Funktionsweise von Schlüsseln). Der Code simuliert das Wechseln zwischen zwei Registerkarten durch Drücken der Schaltflächen – der auskommentierte Abschnitt des Codes von 2 Zeilen ersetzt den unkommentierten und umgekehrt. Wir erstellen 2 Listen mit jeweils 50000 Zeilen (abhängig von der Leistung Ihres Computers – versuchen Sie zur Verdeutlichung, mit dieser Figur zu spielen, wenn sie zu schnell oder zu langsam arbeitet) mit leicht unterschiedlichen Stilen.

Wie es funktioniert, kann sicher jeder selbst überprüfen, also komme ich direkt zu den Schlussfolgerungen:

  1. Wenn ich React-way auf meinem Laptop durcharbeite, dauert das Umschalten zwischen Registerkarten 7 bis 10 Sekunden

  2. bei Durcharbeiten des Versteckens display:none\display:block – Umschaltung von 1,5 auf 2,5 Sekunden

Es scheint, dass die Fragen entfernt wurden – Sie können sie verwenden, aber schauen wir uns die Speicherzuweisung für chrome.exe an (für win10 – finden Sie sie über die Suche nach “Ressourcenmonitor”):

  1. Der Speicherverbrauch liegt beim Rendern mit React-Methoden im Bereich von 600-1200 MB

  2. von 1800 bis 3200 MB beim Ausblenden von Registerkarten durch Stile

Fazit: Für Twitter und Einstellungen / Benutzer-Tabs ist es eine sehr gute Option, aber wenn etwas möglicherweise stärker geladen ist oder eine größere (oder unvorhersehbare) Anzahl schwerer Tabs aufweist, ist es besser, dies nicht zu tun (diese Schlussfolgerung wurde nicht in die Übersetzung des Artikels, um Intrigen zu retten ).

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *