Reaktin komponenttien elinkaarikoukkujen käytön tarkistaminen Asyncin renderointia odotettaessa

Jos olet selanut dokumentaatiota tai pitänyt silmällä React-tiimin neuvoja, olet todennäköisesti lukenut, että sinun ei tule käsitellä tilauksia tai sivuvaikutuksia rakentajassa tai komponentissaWillMount.

Vaikka ohjeet ovat selkeät, näiden ohjeiden perusteluja ei ole perusteellisesti tarkennettu, tosin ei ilman syytä. Lyhyt selitys on, että Fiberin asynkronisen renderoinnin toteutustiedot, jotka motivoivat näitä ohjeita, eivät ole täysin rajattuja.

Koska Fiberin asynk-renderointia ei ole vielä otettu käyttöön, joidenkin elinkaaren käyttöä koskevien viisauksien huomiotta jättäminen ei ehkä vielä ole hammastanut sinua. Jatkossa tämä saattaa muuttua, ja sitä me tutkimme tässä artikkelissa.

Selvennys: Onko kuitu valmis?

Jos Fiberin async-renderointi ei ole valmis menemään, saatat miettiä, myikö joukkue sinulle väärennöslaskun. Voit olla varma, että näin ei ole. Kuidun uusi moottori, tai tarkemmin sanoen täsmäytysprosessi, on otettu käyttöön React v16: n kanssa. Näin ollen emme voi vielä vaihtaa pyydyksiä synkronisesta renderöinnistä priorisoituihin renderöintiin.

Kuinka vaikutus elinkaareihin vaikuttaa?

Viime kädessä, emme tiedä, kunnes asynk-hahmonnus on asetettu kiveen. Muuten React-joukkue olisi sanonut niin paljon. Mutta tilauksista ja sivuvaikutuksista voidaan tehdä turvallisia johtopäätöksiä. Ja sitä me tutkimme.

Yksinkertaisuuden vuoksi tässä on esimerkki tilaamisesta rakennusvälineen mediakyselyluetteloon, mikä ei tällä hetkellä aiheuta meille ongelmia:

Ennen kuin asynk-hahmonnus on käytössä, meillä ei ole ongelmia, koska voimme antaa komponentille seuraavat takuut:

  1. Suunnittelijaa seuraa synkronisesti komponenttiWillMount, jos valitsemme sen käytön, ja sitten renderoidaan. Tärkeää on, että meitä ei keskeytetä ennen renderöintia. Tämän takia voimme edelleen taata ...
  2. Jos komponentti irtoaa tulevaisuudessa, komponentti WillUnmount puhdistaa tapahtuman kuuntelijan (tilauksen) etukäteen. Tämä tarkoittaa, että ikkunassa ei ole mediakyselyluettelon kautta viitettä komponentin käsittelemiseenMediaEvent-menetelmään, minkä ansiosta asennettava komponentti voidaan kerätä roskiksi ja välttää siten muistivuotoja. Tämän puhdistamatta jättäminen kerran ei olisi iso asia, mutta komponentin uudelleenasennus ja lisää kuuntelijoita voi aiheuttaa ongelmia sovelluksen elinaikana.
On yksi varoitus: virherajat. Kosketan sitä vähän.

Joten mikä muuttuu async-renderoinnissa?

Pääset oikeaan pisteeseen: monet luokkakomponenttiesi elinkaarimenetelmät voivat ampua useammin kuin kerran. Tämä johtuu siitä, että Fiberin täsmäytysprosessi antaa Reaktylle mahdollisuuden saada aikaan tekemänsä työn. Annetaan päälangan käsitellä jotain, joka on näytettävä kiireellisesti, kuten animaatio. Tähän voi sisältyä jo valmiiden töiden heittäminen, mukaan lukien mahdollisesti rakentajan, komponentinWillMountin, renderöinnin, komponentinWillUpdate ja komponentinWillReceptionProps kutsut.

KomponenttiDidUpdate ja komponenttiDidMount kutsutaan vasta kun React on suorittanut muutokset isäntäympäristöönsä. Näin vältetään nämä asiat. Puhdistuksen tai 'repiä' komponentin komponentissaWillUnmount tulee heijastaa komponenttia komponenttiDidMount. Tämän koukun kutsumisen epäonnistumisen varmistaminen ei ole ongelmallista.

Siksi meidän on käsiteltävä tilauksia ja sivuvaikutuksia komponentissaDidMount. Konstruktorissa ja komponentissaWillMount tapahtuvat sivuvaikutukset sisältävät useimmiten verkkopyynnöt. Niille on erityisen hankala soittaa useita kertoja, kun ne johtavat mutaatioihin sovelluksen taustatietojen varastoihin.

Viimeinen huomautus.

Kuten minä, olette voinut olettaa, että Reaktin ensimmäinen renderöinti on taatusti aina synkronista. Mutta tämä ei välttämättä ole tapaus!

Brian Vaughn (joka on React-tiimin jäsen) kertoi minulle, että tämänhetkinen tarkoitus on, että ensimmäinen renderöinti synkronoidaan oletuksena, kun valinnainen asynkki on opt-in. Hän lisäsi, että matalan prioriteetin ensimmäinen renderöinti voi olla arvokas, jos esimerkiksi Reaktin isäntäsäiliö ei ole vielä valmis. Tätä on selvästi sovellettavissa silloin, kun HTML-runko koostuu useammasta kuin yhdestä div-osasta, jonka React voi antaa.

Katso visuaalinen tarkistusluettelo siitä, mitä on turvallista suorittaa ja missä, katso Brianin ydin.

Mihin tarkoitukseen komponentti WillMount toimii?

Käyttötapa on hyvin kapea. Kehittäjät lainaavat usein komponenttiWillMount-sovelluksen kahta haluttua ominaisuutta. He ovat:

  1. setState voidaan kutsua komponentistaWillMount toisin kuin rakentaja.
  2. SetState komponentissaWillMount ei aiheuta kahta renderointia, jos se tapahtuu synkronoidusti ennen renderöintia, toisin kuin komponenttiDidMount.

Samoin syy komponenttiWillMount pidettiin alun perin kooditietokannassa, kuten Sebastian Markbåge selittää ehdotuksessa komponenttiWillMountin poistoon, jotta se käsittelisi sivuvaikutusta, joka voi olla synkroninen (jos paikallisessa välimuistissa oli haluttu tieto) tai asynkroninen. Nykyään, kun hänen esittelykoodilohkonsa välittää, getInitialState, es6-luokan rakentajat ja es7-omaisuuden alustajat vastaavat tähän tarkoitukseen.

Kaikesta edellä sanotusta komponenttiWillMountista aloitettu luku-vain GET-pyyntö voi olla hyödyllinen. Hitaasti tuotettavalla laitteella, esimerkiksi keskimääräisellä matkapuhelimella, on mahdollista säästää muutama sata millisekuntia aloittamalla pyyntö täällä komponenttiDidMount-sovelluksen sijasta. Tällaisen pyynnön tulisi tietysti olla idempotentti / vain luku -tyyppinen, koska se voi laukaista useamman kerran.

Kun hahmonnetaan palvelimelle, komponenttiWillMount on edelleen ainoa elinkaarimenetelmä, jota kutsutaan muuksi kuin rakentajaksi, joten on mahdollista, että siellä on joitain käyttötapauksia. Koska en ole yrittänyt palvelinpuolen hahmonnusta itselleni, en osaa tarkentaa paljon aiheeseen.

Joten ovatko nämä varoitukset merkityksellisiä vain async-hahmonnuksen ollessa käynnissä?

Kuten Brian huomautti minulle, ei aivan. React v16: n kanssa käyttöön otetut virherajat voivat myös johtaa komponentinWillMount ja komponenttiWillUpdate-kutsun käynnistämiseen ilman vastaavia komponenttiDidMount ja komponenttiDidUpdate!

Onko muita muutoksia, jotka ovat varovaisia?

React aloitti äskettäin RFC (Request For Comment) -prosessin, jonka avulla laajempi yhteisö voi keskustella ideoista. Kaksi ensimmäisestä RFC: stä on Reaktin ydinryhmän jäseniä ja keskustelevat merkittävistä mahdollisista muutoksista.

  1. Andrew Clark lähetti RFC: n kontekstiliittymän muutoksista. Toivottavasti tämä helpottaa joitain vaikeuksista, jotka pitäisi saada liikkuessa shouldComponentUpdate-yrittäessäsi lähettää tilaa komponenttipuusta. RFC on täällä.
  2. Brian lähetti RFC: n asynk-turvallisille, staattisille elinkaarikoukkuille. Tähän sisältyy pääasiassa komponenttiWillMount, komponenttiWillUpdate ja komponenttiWillReceieveProps vähentäminen vähitellen. Kaksi uutta staattista koukkua ehdotetaan: prefetch ja deriveStateFromProps. Voit lukea lisää ehdotuksesta täältä ja RFC: stä täältä. Toivottavasti tämä artikkeli antoi sinulle hyvää tietoa siitä, miksi näitä muutoksia ehdotetaan :).
  3. Edellä mainitussa ehdotuksessa Brian kiusasi myös tulevaa RFC: tä uutta SSR-koukkua varten: komponenttiDidServerRender, korvaamalla komponentin WillMount palvelimella.

Muista, että nämä ovat varhaisia ​​ehdotuksia!

Kirjailijasta

Olen Adelaidessa sijaitseva australialainen kehittäjä, joka on innostunut sekä edestä että takaosaan tapahtuvasta kehityksestä JavaScriptin avulla! Julkaisin äskettäin ensimmäisen avoimen lähdekoodin kirjaston React: React-MQL-Manager -ohjelmaan. Tässä on yksinkertainen demo, joka integroituu React Router v4: n kanssa reagoivaan reititykseen!

Etsin tällä hetkellä ensimmäistä etuosa- tai koko pino-asentoa. Voit tavoittaa minut sähköpostitse tai sanoa hei minulle twitterissä: @awebofbrown.

Erityiskiitokset

Suuri kiitos Brian Vaughnille, Reaktin ydinryhmästä, ajanjakson lukemisesta artikkeliluonnoksesta sekä ehdotusten ja korjausten tekemisestä. Reaktin parissa työskentelemisen lisäksi Brian on kirjoittanut joitain hienoja avoimen lähdekoodin kirjastoja, kuten React-virtualisoitu ja JS-Search, sekä auttanut vastaamaan yhteisökysymyksiin sellaisilla foorumeilla kuten StackOverflow.