A React shouldcomponentUpdate demystified

A React fejlesztése közben elgondolkodott már azon, hogy mikor és miért futtatják az alkatrészek render () metódusát? Vagy mikor érdemes kevésbé nyilvánvaló életciklus-módszereket használni a ComponentUpdate ()?

Ha a válasz igen, akkor alkalmazásának teljesítményproblémái lehetnek. Olvassa el, és könnyedén kijavíthatja őket.

Az egész abban áll, hogy a React hogyan működik a motorháztető alatt. A React nagy ígérete, hogy gyorsan lángol az elemek megjelenítésével egy oldalon.

Ehhez a React a memóriában tartja a DOM két verzióját:

  • a DOM jelenleg megjelenített verziója
  • a DOM következő megjelenítendő verziója

Összehasonlítja a kettőt, és csak a megváltozott részekkel frissíti a megjelenített DOM-ot. Ezt a folyamatot faegyeztetésnek nevezzük. A megbékélés szempontjából értékelt fa gyökere egy olyan összetevő, amely a kellékeket megváltoztatta.

Nagy. Akár tervezte, akár nem, a webalkalmazás bizonyos mértékig követi a tároló / prezentációs összetevők felosztását. A definíciókat itt és itt találja. Ez azt jelenti, hogy az alkalmazás minden egyes összetett nézete egy olyan konténerkomponensből készül, amely megtartja a logikát, és sok gyermekként csak a komponenseket jeleníti meg.

Ez nagyon jó minta. Ha közelebbről megnézi, ez azt jelenti, hogy a nézet bármilyen felhasználói interakciója hatással lesz magára a tárolóra, és megjeleníti annak és annak összes gyermekének megjelenítését. Tegyük fel, hogy van egy listája olyan elemekkel, amelyekben a kép, a kép és a „Hozzáadás a kedvencekhez” sárga csillagszerű gomb látható. A listaelem minimális modellje a következő lehet:

product = { imageUrl: '...', title: '...', isFavourite: false }

A kedvencek listája egy másik adatforrásból származhat. Ettől függetlenül az összetevői szervezete valószínűleg így néz ki:

A kezelőt a felhasználó kattintására hívják meg, és elmenti az információszerver oldalt (vagy fennállnak egy boltban, vagy bármi más), és megváltoztatja az this.props.elements fájlt.

Egyetlen kattintás eredménye kiváltja a tároló és a lista összes sorának megjelenítését, csak egy jelölőnégyzet frissítéséhez.

Itt kell játszania a shouldComponentUpdate () játékot. Megmondhatja a React-nak, hogy ne jelenjen meg olyan sorokat, amelyeknek nem kell ezt a módszert használniuk.

class ListItem extends Component { shouldComponentUpdate(nextProps, nextState) { return nextProps.isFavourite != this.props.isFavourite; } ... }

Itt van egy konkrét eset: egy piactéri alkalmazásprojekten termékkezelési nézetünk volt az eladók számára. A listának volt egy „többet terhel, amikor a felhasználó lefelé görget” mintája, és egy soron belüli elem műveletek „mutatták / rejtették” az egyes termékek láthatóságának beállításához. Minden rendben volt, amikor az eladók <100 terméket kezeltek az irányítópulton. Aztán egy adott eladó több mint 300 terméket kezdett meg hirdetni és hirdetni…

~ 600 ms késés volt, mire a felhasználói felület frissült, miután a felhasználó rákattintott az „engedélyezés / letiltás” ikonra. A késést a végfelhasználó mindenképpen láthatta. A Chrome profiloló segítségével azt láttuk, hogy a React ~ 2ms-ra volt szükség egyetlen sor megjelenítéséhez. 300-szor ... 600ms-ig jutottunk. Hozzáadtuk a shouldComponentUpdate () ellenőrzéseket a megfelelő feltételekhez. A renderelési idő a felhasználói kattintás után 10 ms alatt lett ...

Összeállítottam egy kis projektet, amely lehetővé teszi az eset itteni reprodukálását. Futtassa és olvassa el a kód megjegyzéseket, hogy lássa a varázslatot.

Figyelem a Redux felhasználók számára

A fent leírt probléma gyakrabban fordulhat elő, ha Redux-ot használ, és újraválasztja (vagy hasonló „bolt alapú” művelet-csővezeték-könyvtárakat).

A Redux és az újraválasztás segítségével a műveleteket a boltba tolja, és a hallgatókat csatlakoztatja a változtatások tárolásához, más néven kiválasztók. A szelektorok világszerte elérhetők az alkalmazásban és egy nagy alkalmazásban, nagyon sok komponens számára könnyen azonos térképekhez rendelhető. Az áruházban végrehajtott változtatások a kellékeket érintő változásokat indíthatnak el, így egyes alkotóelemeknél teljesen lényegtelenek.

Íme a zavaros tanács: ne használja a shouldComponentUpdate () alkalmazást a megjelenítések megakadályozására ilyen esetekben. A shouldComponentUpdate belsejében lévő logikának csak azt kell megvizsgálnia, ami releváns az összetevő szempontjából. Soha nem szabad előre látnia azokat a kontextusokat, amelyekben az összetevőt használják. Ennek oka csak az, hogy a kódja gyorsan fenntarthatatlanná válik.

Ha ilyen problémái vannak, az azt jelenti, hogy az áruház felépítése hibás, vagy a kiválasztók nem elég specifikusak. El kell jutnia egy új modellezési körbe.

Ajánlom ezeket a félelmetes kazánlapokat. Elősegíti az üzletek beágyazását magas szintű konténerenként, az egész alkalmazáson átívelő kulcsadat-struktúrák globális területtel. Ez elég biztonságos megközelítés az üzletmodellezési hibák elkerülésére.

Köszönöm, hogy elolvasta! Ha tetszett, nyomja meg az alábbi taps gombot. Ez segít más embereknek látni a történetet.