Muuttuvan datan hallinta: Syväsukellus Reactin experimental_useMutableSource-tilaukseen

Jatkuvasti kehittyvässä frontend-kehityksen maailmassa suorituskyky on ensisijaisen tärkeää. Sovellusten monimutkaistuessa dynaamisten tietolähteiden tehokas hallinta ja tilaaminen muuttuu kriittiseksi haasteeksi. React tarjoaa deklaratiivisella paradigmallaan tehokkaita työkaluja tilanhallintaan. Kuitenkin tietyissä edistyneissä skenaarioissa, erityisesti niissä, jotka sisältävät matalan tason muuttuvia tietorakenteita tai ulkoisia muuttuvia säilöjä, kehittäjät etsivät usein tarkempaa hallintaa ja optimoituja tilausmekanismeja. Juuri tässä kohtaa Reactin experimental_useMutableSource-hook nousee esiin tehokkaana, vaikkakin kokeellisena, ratkaisuna.

Tämä kattava opas sukeltaa syvälle experimental_useMutableSource-hookiin, tutkien sen tarkoitusta, ydinkäsitteitä, käytännön sovelluksia ja taustalla olevia periaatteita, jotka tekevät siitä mullistavan työkalun korkeasti optimoiduille React-sovelluksille. Käsittelemme sen kokeellista luonnetta, ymmärrämme sen paikan Reactin samanaikaisuuden kehityspolulla ja tarjoamme käytännön neuvoja kehittäjille, jotka haluavat hyödyntää sen voimaa.

Muuttuvien datatilausten tarpeen ymmärtäminen

Perinteinen Reactin tilanhallinta, usein hookien kuten useState ja useReducer kautta, perustuu muuttumattomiin päivityksiin. Kun tila muuttuu, React renderöi uudelleen komponentit, jotka riippuvat kyseisestä tilasta. Tämä muuttumattomuus takaa ennustettavuuden ja yksinkertaistaa Reactin vertailualgoritmia. On kuitenkin skenaarioita, joissa luonnostaan muuttuvien tietorakenteiden käsittely on väistämätöntä tai tarjoaa merkittäviä suorituskykyetuja:

• Ulkoiset muuttuvat säilöt: Sovellukset saattavat integroitua kolmannen osapuolen kirjastoihin tai omiin tietosäilöihin, jotka hallitsevat tilaa muuttuvasti. Esimerkkejä ovat tietyt pelimoottorit, reaaliaikaiset yhteistyömuokkaustyökalut tai erikoistuneet dataruudukot, jotka paljastavat muuttuvia API-rajapintoja.
• Suorituskykykriittiset tietorakenteet: Erittäin tiheiden päivitysten tai hyvin suurten, monimutkaisten tietorakenteiden kohdalla toistuvat täydelliset muuttumattomuustarkistukset voivat muodostua pullonkaulaksi. Tällaisissa tapauksissa huolellisesti hallittu muuttuva data, jossa vain tarvittavat osat päivitetään tai käytetään tehokkaampaa vertailustrategiaa, voi tarjota ylivoimaisen suorituskyvyn.
• Yhteentoimivuus ei-React-järjestelmien kanssa: Kun React yhdistetään ei-React-komponentteihin tai -järjestelmiin, jotka toimivat muuttuvan datan kanssa, tarvitaan usein suora tilausmekanismi.

Näissä tilanteissa standardi Reactin tilausmalli saattaa sisältää jatkuvaa kyselyä (polling), monimutkaisia kiertoteitä tai tehottomia uudelleenrenderöintejä. useMutableSource-hookin tavoitteena on tarjota ensiluokkainen, optimoitu ratkaisu näiden ulkoisten muuttuvien tietolähteiden tilaamiseen.

Esittelyssä experimental_useMutableSource

experimental_useMutableSource-hook on suunniteltu kuromaan umpeen kuilu Reactin renderöintimekanismin ja ulkoisten muuttuvien tietolähteiden välillä. Sen ensisijainen tavoite on sallia React-komponenttien tilata muutoksia muuttuvasta tietolähteestä asettamatta tiukkoja muuttumattomuusvaatimuksia itse lähteelle. Se tarjoaa suoremman ja potentiaalisesti suorituskykyisemmän tavan integroitua muuttuvaan tilaan verrattuna manuaaliseen tilauksenhallintaan.

Ytimessään useMutableSource toimii ottamalla vastaan source-lähteen, getSnapshot-funktion ja subscribe-funktion. Käydään nämä komponentit läpi:

useMutableSource:n ydinkomponentit

1. Lähde (Source)

source on yksinkertaisesti muuttuva tietosäilö tai objekti, jonka muutoksia React-komponenttisi tulee tilata. Tämä voi olla globaali muuttuva objekti, luokan instanssi tai mikä tahansa JavaScript-arvo, joka voi muuttua ajan myötä.

2. getSnapshot-funktio

getSnapshot-funktion tehtävänä on lukea nykyinen arvo source-lähteestä. React kutsuu tätä funktiota aina, kun sen tarvitsee määrittää tietolähteen nykyinen tila päättääkseen, onko uudelleenrenderöinti tarpeen. Avainasemassa on, että getSnapshot:n ei tarvitse taata muuttumattomuutta. Se ainoastaan palauttaa nykyisen arvon.

Esimerkki:

            const getSnapshot = (source) => source.value;

            

              
                Copy
              
            
          

3. subscribe-funktio

subscribe-funktio on tilausmekanismin sydän. Se ottaa argumenteikseen source-lähteen ja callback-funktion. Kun muuttuva tietolähde muuttuu, subscribe-funktion tulisi kutsua tätä callback-funktiota ilmoittaakseen Reactille, että data on mahdollisesti muuttunut. Tämän jälkeen React kutsuu getSnapshot-funktiota arvioidakseen tilan uudelleen.

subscribe-funktion tulee myös palauttaa unsubscribe-funktio. Tämä on kriittistä, jotta React voi siivota tilauksen komponentin poistuessa (unmount), estäen muistivuodot ja odottamattoman käytöksen.

Esimerkki:

            
const subscribe = (source, callback) => {
  // Oletetaan yksinkertaisuuden vuoksi, että lähteellä on 'addListener'-metodi
  source.addListener('change', callback);

  return () => {
    source.removeListener('change', callback);
  };
};

            

              
                Copy
              
            
          

Miten useMutableSource toimii konepellin alla

Kun käytät useMutableSource-hookia komponentissa:

1. React alustaa hookin kutsumalla getSnapshot-funktiota saadakseen alkuarvon.
2. Sitten se kutsuu subscribe-funktiota, välittäen sille source-lähteen ja Reactin hallinnoiman callback-funktion. Palautettu unsubscribe-funktio tallennetaan sisäisesti.
3. Kun tietolähde muuttuu, subscribe-funktio kutsuu Reactin callback-funktiota.
4. React vastaanottaa ilmoituksen ja määrittääkseen, tarvitaanko päivitystä, se kutsuu getSnapshot-funktiota uudelleen.
5. React vertaa uutta tilannekuvan arvoa edelliseen. Jos ne eroavat, React ajoittaa komponentin uudelleenrenderöinnin.
6. Kun komponentti poistuu, React kutsuu tallennettua unsubscribe-funktiota siivotakseen tilauksen.

Kriittinen näkökohta tässä on, että useMutableSource luottaa siihen, että subscribe-funktio on tehokas ja getSnapshot-funktio on kohtuullisen nopea. Se on suunniteltu skenaarioihin, joissa nämä operaatiot ovat suorituskykyisempiä kuin monimutkaisten, usein muuttuvien tietojen täydellisten muuttumattomuustarkistusten aiheuttama ylikuormitus.

Käytännön käyttötapaukset ja esimerkit

Kuvitellaan, miten experimental_useMutableSource-hookia voidaan soveltaa todellisissa skenaarioissa.

Esimerkki 1: Globaalin muuttuvan laskurin tilaaminen

Kuvittele yksinkertainen globaali laskuriobjekti, jota voidaan muokata mistä tahansa sovelluksessasi.

            
// --- Mutable Data Source ---
let counter = {
  value: 0,
  listeners: new Set(),

  increment() {
    this.value++;
    this.listeners.forEach(listener => listener());
  },

  subscribe(callback) {
    this.listeners.add(callback);
    return () => {
      this.listeners.delete(callback);
    };
  },

  getSnapshot() {
    return this.value;
  }
};

// --- React Component ---
import React, { experimental_useMutableSource } from 'react';

function CounterDisplay() {
  const count = experimental_useMutableSource(
    counter, // The source
    (source) => source.getSnapshot(), // getSnapshot function
    (source, callback) => source.subscribe(callback) // subscribe function
  );

  return (
    

      
Nykyinen lukema: {count}
       counter.increment()}>Kasvata
    
  );
}

// In your App component:
// ReactDOM.render(, document.getElementById('root'));

            

              
                Copy
              
            
          

Tässä esimerkissä:

• counter on muuttuva lähteemme.
• getSnapshot palauttaa suoraan source.value.
• subscribe käyttää yksinkertaista Set-rakennetta kuuntelijoiden hallintaan ja palauttaa tilauksen peruutusfunktion.

Kun painiketta napsautetaan, counter.increment()-metodia kutsutaan, mikä muuttaa counter.value-arvoa ja kutsuu sitten kaikkia rekisteröityjä kuuntelijoita. React vastaanottaa tämän ilmoituksen, kutsuu getSnapshot-funktiota uudelleen, havaitsee arvon muuttuneen ja renderöi CounterDisplay-komponentin uudelleen.

Esimerkki 2: Integrointi Web Workerin kanssa ulkoistettuja laskutoimituksia varten

Web Workerit ovat erinomaisia laskennallisesti raskaiden tehtävien siirtämiseen pois pääsäikeestä. Ne kommunikoivat viestien kautta, ja workerilta takaisin tulevan tilan hallinta voi olla erinomainen käyttötapaus useMutableSource-hookille.

Oletetaan, että sinulla on workeri, joka käsittelee dataa ja lähettää takaisin muuttuvan tulosobjektin.

            
// --- worker.js ---
// Assume this worker receives data, performs computation,
// and maintains a mutable 'result' object.

let result = { data: null, status: 'idle' };
let listeners = new Set();

self.onmessage = (event) => {
  if (event.data.type === 'PROCESS_DATA') {
    result.status = 'processing';
    // Simulate computation
    setTimeout(() => {
      result.data = event.data.payload.toUpperCase();
      result.status = 'completed';
      listeners.forEach(listener => listener()); // Notify main thread
    }, 1000);
  }
};

// Functions for the main thread to interact with the worker's state
self.getResultSnapshot = () => result;
self.subscribeToWorkerResult = (callback) => {
  listeners.add(callback);
  return () => {
    listeners.delete(callback);
  };
};

            

              
                Copy
              
            
          

            
// --- Main Thread React Component ---
import React, { experimental_useMutableSource, useRef, useEffect } from 'react';

const worker = new Worker('./worker.js');

const workerSource = {
  // This object acts as a proxy to the worker's methods
  // In a real app, you'd need a more robust way to pass these functions
  // or make the worker's methods globally accessible if possible.
  getSnapshot: () => worker.getResultSnapshot(),
  subscribe: (callback) => worker.subscribeToWorkerResult(callback)
};

function WorkerProcessor() {
  const [workerResult] = experimental_useMutableSource(
    workerSource, // The source object containing our functions
    (source) => source.getSnapshot(),
    (source, callback) => source.subscribe(callback)
  );

  useEffect(() => {
    // Send data to worker when component mounts
    worker.postMessage({ type: 'PROCESS_DATA', payload: 'some input' });
  }, []);

  return (
    

      
Workerin tila: {workerResult.status}
      
Tuloksen data: {workerResult.data || 'N/A'}
    
  );
}

// In your App component:
// ReactDOM.render(, document.getElementById('root'));

            

              
                Copy
              
            
          

Tämä esimerkki osoittaa, kuinka useMutableSource voi abstrahoida pääsäikeen ulkopuolisen prosessin viestinnän ja tilanhallinnan, pitäen React-komponentin siistinä ja renderöintiin keskittyneenä.

Esimerkki 3: Edistyneet reaaliaikaiset dataruudukot tai kartat

Harkitse monimutkaista dataruudukkoa, jossa rivejä ja soluja voidaan päivittää erittäin nopeasti, ehkä WebSocket-syötteestä. Koko ruudukon uudelleenrenderöinti jokaisen pienen muutoksen yhteydessä saattaa olla liian kallista. Jos ruudukkokirjasto tarjoaa muuttuvan API-rajapinnan datalleen ja tavan tilata hienojakoisia muutoksia, useMutableSource voi olla tehokas työkalu.

Esimerkiksi hypoteettisella MutableDataGrid-komponentilla saattaisi olla:

• dataStore-objekti, jota muutetaan suoraan.
• dataStore.subscribe(callback)-metodi.
• dataStore.getSnapshot()-metodi.

Sitten käyttäisit useMutableSource-hookia yhdistämään React-komponenttisi tähän dataStore-säilöön, mikä mahdollistaisi ruudukon tehokkaan renderöinnin, joka tapahtuu vain, kun data todella muuttuu ja Reactin sisäiset mekanismit havaitsevat sen.

Milloin käyttää (ja milloin ei kannata käyttää) useMutableSource:a

experimental_useMutableSource-hook on tehokas työkalu, mutta se on suunniteltu tiettyihin käyttötapauksiin. On tärkeää ymmärtää sen rajoitukset ja milloin muut React-mallit saattavat olla sopivampia.

Milloin harkita useMutableSource:a:

• Käyttöliittymä ulkoisiin muuttuviin kirjastoihin: Kun integroidutaan kirjastoihin, jotka hallitsevat omaa muuttuvaa tilaansa ja tarjoavat tilaus-API:t (esim. tietyt grafiikkakirjastot, fysiikkamoottorit tai erikoistuneet käyttöliittymäkomponentit).
• Suorituskyvyn pullonkaulat monimutkaisen muuttuvan datan kanssa: Jos olet profiloinut sovelluksesi ja havainnut, että muuttumattomien kopioiden luomisen ylikuormitus erittäin suurista tai usein muuttuvista tietorakenteista on merkittävä suorituskykyongelma, ja sinulla on muuttuva lähde, joka tarjoaa tehokkaamman tilausmallin.
• Reactin yhdistäminen ei-Reactin muuttuvaan tilaan: Hallittaessa tilaa, joka on peräisin React-ekosysteemin ulkopuolelta ja on luonnostaan muuttuva.
• Kokeelliset samanaikaisuusominaisuudet: Reactin jatkaessa kehitystään samanaikaisuusominaisuuksien parissa, useMutableSource:n kaltaiset hookit on suunniteltu toimimaan harmonisesti näiden edistysaskelten kanssa, mahdollistaen kehittyneempiä tiedonhaku- ja renderöintistrategioita.

Milloin välttää useMutableSource:a:

• Standardi sovelluksen tila: Tyypilliselle sovelluksen tilalle, jota hallitaan React-komponenttien sisällä (esim. lomakekentät, käyttöliittymän valinnat, haettu data, jota voidaan käsitellä muuttumattomana), useState, useReducer tai kirjastot kuten Zustand, Jotai tai Redux ovat yleensä sopivampia, yksinkertaisempia ja turvallisempia.
• Selkeän muuttuvan lähteen ja tilauksen puute: Jos tietolähteesi ei ole luonnostaan muuttuva tai ei tarjoa siistiä tapaa tilata muutoksia ja peruuttaa tilausta, joudut rakentamaan kyseisen infrastruktuurin itse, mikä saattaa vesittää useMutableSource:n käytön tarkoituksen.
• Kun muuttumattomuus on yksinkertaista ja hyödyllistä: Jos tietorakenteesi ovat pieniä tai muuttumattomien kopioiden luomisen kustannukset ovat vähäisiä, standardeissa React-malleissa pysyminen johtaa ennustettavampaan ja ylläpidettävämpään koodiin. Muuttumattomuus yksinkertaistaa virheenjäljitystä ja tilamuutosten päättelyä.
• Ylioptimointi: Ennenaikainen optimointi voi johtaa monimutkaiseen koodiin. Mittaa aina suorituskyky ennen kuin otat käyttöön edistyneitä työkaluja kuten useMutableSource.

useMutableSource:n kokeellinen luonne ja tulevaisuus

On kriittistä toistaa, että experimental_useMutableSource on todellakin kokeellinen. Tämä tarkoittaa:

• API:n vakaus: API saattaa muuttua tulevissa React-versioissa. Tarkka allekirjoitus tai käyttäytyminen voi muuttua.
• Dokumentaatio: Vaikka ydinkäsitteet on ymmärretty, laaja dokumentaatio ja yleinen yhteisön omaksuminen saattavat olla vielä kehittymässä.
• Työkalujen tuki: Virheenjäljitystyökaluilla ja lintereillä ei välttämättä ole täyttä tukea kokeellisille ominaisuuksille.

Reactin tiimi esittelee kokeellisia ominaisuuksia kerätäkseen palautetta ja hienosäätääkseen API-rajapintoja ennen niiden vakauttamista. Tuotantosovelluksissa on yleensä suositeltavaa käyttää vakaita API-rajapintoja, ellet sinulla ole erittäin spesifistä, suorituskykykriittistä tarvetta ja olet valmis sopeutumaan mahdollisiin API-muutoksiin.

useMutableSource:n sisällyttäminen on linjassa Reactin jatkuvan työn kanssa samanaikaisuuden, suspensen ja parannetun suorituskyvyn parissa. Kun React pyrkii käsittelemään samanaikaista renderöintiä ja mahdollisesti renderöimään käyttöliittymän osia itsenäisesti, mekanismit ulkoisten tietolähteiden tehokkaaseen tilaamiseen, jotka saattavat päivittyä milloin tahansa, tulevat tärkeämmiksi. useMutableSource:n kaltaiset hookit tarjoavat matalan tason primitiivit, joita tarvitaan näiden edistyneiden renderöintistrategioiden rakentamiseen.

Keskeisiä huomioita samanaikaisuudesta

Samanaikaisuus Reactissa antaa sille mahdollisuuden keskeyttää, pysäyttää ja jatkaa renderöintiä. Jotta useMutableSource:n kaltainen hook toimisi tehokkaasti samanaikaisuuden kanssa:

• Uudelleenkutsuttavuus (Reentrancy): getSnapshot- ja subscribe-funktioiden tulisi ihanteellisesti olla uudelleenkutsuttavia, eli niitä voidaan kutsua useita kertoja samanaikaisesti ilman ongelmia.
• getSnapshot:n ja subscribe:n tarkkuus: getSnapshot:n tarkkuus todellisen tilan heijastamisessa ja subscribe:n luotettavuus muutoksista ilmoittamisessa ovat ensisijaisen tärkeitä, jotta Reactin samanaikaisuuden ajoitin voi tehdä oikeita päätöksiä renderöinnistä.
• Atomisuus: Vaikka lähde on muuttuva, getSnapshot- ja subscribe-funktioiden sisäisten operaatioiden tulisi pyrkiä jonkinasteiseen atomisuuteen tai säieturvallisuuteen, jos toimitaan ympäristöissä, joissa se on huolenaihe (vaikka tyypillisesti Reactissa se tapahtuu yhden tapahtumasilmukan sisällä).

Parhaat käytännöt ja sudenkuopat

Kun työskentelet experimental_useMutableSource:n kanssa, parhaiden käytäntöjen noudattaminen voi estää yleisiä ongelmia.

Parhaat käytännöt:

• Profiloi ensin: Profiloi aina sovelluksesi varmistaaksesi, että muuttuvien datatilausten hallinta on todella suorituskyvyn pullonkaula, ennen kuin turvaudut tähän hookiin.
• Pidä getSnapshot ja subscribe kevyinä: useMutableSource:lle annettujen funktioiden tulisi olla mahdollisimman kevyitä. Vältä raskaita laskutoimituksia tai monimutkaista logiikkaa niiden sisällä.
• Varmista oikea tilauksen peruutus: subscribe-takaisinkutsun palauttama unsubscribe-funktio on kriittinen. Varmista, että se siivoaa oikein kaikki kuuntelijat tai tilaukset muistivuotojen estämiseksi.
• Dokumentoi lähteesi: Dokumentoi selkeästi muuttuvan tietolähteesi rakenne ja käyttäytyminen, erityisesti sen tilausmekanismi, ylläpidettävyyden vuoksi.
• Harkitse kirjastoja: Jos käytät kirjastoa, joka hallitsee muuttuvaa tilaa, tarkista, tarjoaako se jo React-hookin tai kääreen, joka abstrahoi useMutableSource:n puolestasi.
• Testaa perusteellisesti: Kokeellisen luonteensa vuoksi perusteellinen testaus on välttämätöntä. Testaa erilaisissa olosuhteissa, mukaan lukien nopeat päivitykset ja komponentin poistuminen.

Mahdolliset sudenkuopat:

• Vanhentunut data: Jos getSnapshot ei heijasta tarkasti nykyistä tilaa tai jos subscribe-takaisinkutsu jää väliin, komponenttisi saattaa renderöityä vanhentuneella datalla.
• Muistivuodot: Väärin toteutetut unsubscribe-funktiot ovat yleinen syy muistivuodoille.
• Kilpa-ajotilanteet (Race Conditions): Monimutkaisissa skenaarioissa kilpa-ajotilanteita voi esiintyä muuttuvan lähteen päivitysten ja Reactin uudelleenrenderöintisyklin välillä, jos niitä ei hallita huolellisesti.
• Virheenjäljityksen monimutkaisuus: Muuttuvan tilan ongelmien virheenjäljitys voi olla haastavampaa kuin muuttumattoman tilan kanssa, koska muutoshistoria ei ole yhtä helposti saatavilla.
• Ylikäyttö: useMutableSource:n soveltaminen yksinkertaisiin tilanhallintatehtäviin lisää tarpeettomasti monimutkaisuutta ja vähentää ylläpidettävyyttä.

Vaihtoehdot ja vertailut

Ennen useMutableSource:n käyttöönottoa on syytä harkita vaihtoehtoisia lähestymistapoja:

• useState/useReducer muuttumattomilla päivityksillä: Standardi ja suositeltavin tapa useimmille sovelluksen tiloille. Reactin optimoinnit on rakennettu tämän mallin ympärille.
• Context API: Hyödyllinen tilan jakamiseen komponenttien välillä ilman prop-drillingiä, mutta voi johtaa suorituskykyongelmiin, jos sitä ei optimoida React.memo:lla tai useCallback:lla.
• Ulkoiset tilanhallintakirjastot (Zustand, Jotai, Redux, MobX): Nämä kirjastot tarjoavat erilaisia strategioita globaalin tai paikallisen tilan hallintaan, usein optimoiduilla tilausmalleilla ja kehittäjätyökaluilla. Erityisesti MobX on tunnettu reaktiivisesta, havaittaviin perustuvasta järjestelmästään, joka toimii hyvin muuttuvan datan kanssa.
• Mukautetut hookit manuaalisilla tilauksilla: Voit aina luoda oman mukautetun hookin, joka tilaa manuaalisesti tapahtumalähettimen (event emitter) tai muuttuvan objektin. useMutableSource käytännössä virallistaa ja optimoi tämän mallin.

useMutableSource erottuu, kun tarvitset kaikkein hienojakoisinta hallintaa, käsittelet aidosti ulkoista ja muuttuvaa lähdettä, jota ei ole helppo kääriä muihin kirjastoihin, tai rakennat edistyneitä React-ominaisuuksia, jotka vaativat matalan tason pääsyn datapäivityksiin.

Yhteenveto

experimental_useMutableSource-hook edustaa merkittävää askelta kohti tehokkaampien työkalujen tarjoamista React-kehittäjille erilaisten tietolähteiden hallintaan. Vaikka sen kokeellinen status vaatii varovaisuutta, sen potentiaali suorituskyvyn optimoimiseksi skenaarioissa, jotka sisältävät monimutkaista, muuttuvaa dataa, on kiistaton.

Ymmärtämällä ydinkomponentit – source, getSnapshot ja subscribe-funktiot – ja niiden roolit Reactin renderöintisyklissä, kehittäjät voivat alkaa tutkia sen ominaisuuksia. Muista lähestyä sen käyttöä huolellisesti, priorisoiden aina profilointia ja selkeää ymmärrystä siitä, milloin se tarjoaa todellisia etuja vakiintuneisiin malleihin verrattuna.

Reactin samanaikaisuusmallin kypsyessä useMutableSource:n kaltaiset hookit tulevat todennäköisesti näyttelemään yhä tärkeämpää roolia seuraavan sukupolven korkean suorituskyvyn omaavien, responsiivisten verkkosovellusten mahdollistamisessa. Niille, jotka uskaltautuvat React-kehityksen eturintamaan, useMutableSource:n hallitseminen tarjoaa välähdyksen tehokkaan muuttuvan datan hallinnan tulevaisuuteen.

Vastuuvapauslauseke: experimental_useMutableSource on kokeellinen API. Sen käyttö tuotantoympäristöissä sisältää riskin rikkoutuvista muutoksista tulevissa React-versioissa. Viittaa aina uusimpaan React-dokumentaatioon ajantasaisimman tiedon saamiseksi.