Reakti komponentide elutsükli konksude kasutamise uuesti läbivaatamine Asynci renderduse ootuses

Kui olete sirvinud dokumentatsiooni või jälginud Reacti põhitiimi nõuandeid, olete tõenäoliselt lugenud, et te ei tohiks ehitajas ega komponendis WillMount tellimusi ega kõrvalmõjusid käsitleda.

Ehkki nõuanded on selged, pole nende juhiste tagamaid piisavalt põhjalikult läbi viidud, ehkki mitte ilma põhjuseta. Lühike seletus on see, et Fiberi asünkroonse renderdamise rakenduse üksikasjad, mis neid juhiseid motiveerivad, ei ole täielikult läbi raiutud.

Kuna Fiberi asünkri renderdamine pole veel sisse lülitatud, pole võib-olla mõne elutsükli kasutamisega seotud tarkuse eiramine teid veel hammustanud. Tulevikus võib see muutuda ja seda uurime selles artiklis.

Täpsustus: kas Fiber on valmis?

Kui Fiberi asünkri renderdamine pole veel valmis, siis võiksite küsida, kas meeskond müüs teile võltsitud arve. Võite olla kindel, et see pole nii. Kiudude uus mootor ehk täpsemalt lepitusprotsess on React v16-ga tööle pandud. Sellegipoolest ei saa me veel sünkroonsetest renderdustest käike prioriteetseteks renderdusteks vahetada.

Kuidas mõjutab elutsüklite kasutamist?

Lõppkokkuvõttes ei tea me enne, kui asünkrooni renderdamine on kivisse pandud. Muidu oleks Reakti meeskond sama palju öelnud. Kuid tellimuste ja kõrvalmõjude käsitlemise kohta saame teha ohutuid järeldusi. Ja seda me uurimegi.

Lihtsuse huvides on siin näide konstruktoris meediumipäringute loendi tellimisest, mis praegu ei tekita meile probleeme:

Enne asünkrooni renderdamise lubamist pole meil probleeme, kuna saame komponendi osas anda järgmised garantiid:

  1. Konstruktorile järgneb sünkroonselt komponentWillMount, kui me otsustame seda kasutada, ja siis renderdada. Oluline on see, et meid ei segata enne renderdamist. Seetõttu võime täiendavalt tagada ...
  2. Kui komponent tulevikus lahti monteeritakse, puhastab komponent sündmuse kuulaja (tellimuse) eelnevalt. See tähendab, et aknas ei säilitata meediumipäringute loendi kaudu viidet komponendi käepidemeleMediaEvent, võimaldades seega monteerimata komponenti prügi koguda ja vältides seega mälu leket. Kui seda kord puhastada ei õnnestu, poleks see suur asi, kuid komponendi uuesti paigaldamine ja kuulajate lisamine võib põhjustada probleeme kogu rakenduse eluea jooksul.
On üks hoiatus: veapiirid. Ma puudutan seda natuke.

Mis siis asünkri renderdamisel muutub?

Täpsuse juurde jõudmiseks: paljud teie klassi komponendi elutsükli meetodid võivad käivituda mitu korda. Selle põhjuseks on asjaolu, et Fiberi lepitusprotsess võimaldab Reaktyl saada oma tehtud tööd. Võimaldades põhilõngal käsitleda midagi, mida tuleb kiiresti kuvada, näiteks animatsiooni. See võib hõlmata juba lõpetatud töö viskamist, sealhulgas potentsiaalselt konstruktori, komponentWillMount, renderdamine, komponentWillUpdate ja komponentWillReceptionProps kutsed.

Kuid komponentDidUpdate ja komponentDidMount kutsutakse välja alles pärast seda, kui React on oma hostkeskkonna muudatused läbi viinud. Vältides neid küsimusi. Puhastamine või „rebenemine” komponendisWillUnmount peaks peegeldama seadistust komponendisDidMount. Selle konksu kutsumata jätmise tagamine ei ole problemaatiline.

Seega peame komponentDidMountis tellimusi ja kõrvalmõjusid käsitlema. Ehitajas ja komponentWillMountis esinevad kõrvaltoimed hõlmavad enamasti võrgutaotlusi. Eriti tülikad on neil mitu korda helistada, kui nende tulemuseks on mutatsioonid meie rakenduse taustandmebaasides.

Viimane märkus.

Nagu mina, võisite arvata, et Reakti päris esimene renderdus on tagatud alati sünkroonselt. Kuid see pole tingimata nii!

Brian Vaughn (kes on Reacti tuumikmeeskond) teatas mulle, et praegune kavatsus on esimene renderdamine vaikimisi sünkroonida ja valikuline asünkroon on lubatud. Ta lisas, et madala prioriteediga esimene renderdus võib olla väärtuslik, kui näiteks Reacti hostimahuti pole veel valmis. Ilmselt on see rakendatavam juhul, kui teie HTML-i korpus koosneb enam kui ühest jaotisest, mille jaoks Reakttile renderdada.

Visuaalse kontrollnimekirja selle kohta, mida on ohutu täita ja kus, leiate Briani sisust.

Mis eesmärki teenib komponentWillMount?

Kasutusjuhtum on väga kitsas. Arendajad nimetavad sageli komponendi WillMount kahte soovitavat omadust. Nemad on:

  1. SetState'i saab erinevalt ehitajast kutsuda komponendistWillMount.
  2. SetState komponendisWillMount ei põhjusta kahte renderdamist, kui see toimub sünkroonselt enne renderdamist, erinevalt komponentDidMountist.

Sarnaselt hoiti komponentiWillMount põhjus algselt koodipõhjas, nagu Sebastian Markbåge selgitab komponendiWillMount amortiseerimise ettepanekus, selleks, et käsitseda kõrvalmõju, mis võib olla sünkroonne (kui kohalik vahemälu hoiab soovitud andmeid) või alternatiivselt asünkroonne. Täna, kui tema demonstratsioonkoodiplokk edastab, teenivad getInitialState, es6 klassi konstruktorid ja es7 vara initsiaatorid seda eesmärki.

Kõike seda öeldes võib komponentWillMountist algatatud kirjutuskaitstud GET-taotlus olla kasulik. Aeglaselt renderdatavas seadmes, näiteks keskmises mobiilis, on võimalik paarisaja millisekundi kokku hoida, käivitades päringu siin, mitte komponendiDidMount. Muidugi peaks selline taotlus olema idempotentne / kirjutuskaitstud, kuna see võib käivituda mitu korda.

Serveris renderdamisel on komponentWillMount endiselt ainus elutsüklimeetod, mida nimetatakse muuks kui konstruktoriks, seega on võimalik, et seal leidub ka mõnda kasutusjuhtu. Kuna ma pole üritanud serveripoolset renderdamist, ei oska ma seda teemat eriti täpsustada.

Kas need hoiatused on asjakohased ainult siis, kui asünkri renderdamine on aktiivne?

Nagu Brian mulle osutas, mitte päris. React v16-ga reaalajas käivitatud tõrkepiirid võivad põhjustada komponentideWillMount ja componentsWillUpdate kutsumise ilma vastavate komponentDidMount ja komponentDidUpdate!

Kas on veel mingeid muudatusi, millega tuleks ettevaatlik olla?

Reakt algatas hiljuti RFC (Request For Comment) protsessi, mis võimaldab laiemal kogukonnal ideid arutada. Kaks esimest RFC-d pärinevad Reaketi põhimeeskonna liikmetest, arutades olulisi võimalikke muudatusi.

  1. Andrew Clark esitas RFC konteksti API muudatuste kohta. Loodetavasti leevendab see osa keeruline peaks peaks olema ComponentUpdate, kui proovite komponendipuust allapoole levitada. RFC on siin.
  2. Brian esitas RFC asünkrohutusega staatilise olelustsükli konksude jaoks. See hõlmab põhimõtteliselt komponentide WillMount, componentsWillUpdate ja componentsWillReceieveProps järkjärgulist amortiseerimist. Pakutakse välja kaks uut staatilist konksu: eelhank ja deriveStateFromProps. Lisateavet ettepaneku kohta saate lugeda siit ja RFC siit. Loodetavasti andis see artikkel teile mõne hea ülevaate, miks neid muudatusi pakutakse :).
  3. Eelnimetatud ettepanekus kiusas Brian ka eelseisvat RFC-d uue SSR-konksu jaoks: komponentDidServerRender, võttes serveris komponentWillMount.

Pidage meeles, et need on varajased ettepanekud!

Autori kohta

Olen Adelaide'is asuv Austraalia arendaja, kes on JavaScripti kirglik nii ees- kui ka tagaosa arendamisel! Avaldasin hiljuti oma esimese avatud lähtekoodiga teegi Reaktiks: React-MQL-Manager. Siin on lihtne demo, mis on integreeritud React Router v4-ga reageerivaks marsruutimiseks!

Otsin praegu oma esimest esiosa või täispositsiooni positsiooni. Võite minuga e-posti teel jõuda või öelge twitteris mulle tere: @awebofbrown.

Eriline tänu

Suured tänud Brian Vaughnile Reacti tuumitiimist, kes leidsid aega artikli kavandi lugemiseks ning ettepanekute ja paranduste tegemiseks. Lisaks Reacti kallal töötamisele on Brian kirjutanud ka mõned suurepärased avatud lähtekoodiga raamatukogud, näiteks React-virtualiseeritud ja JS-Search, ning aidanud vastata kogukonna küsimustele foorumites nagu StackOverflow.