Avaa tehokkaiden React-sovellusten potentiaali syväsukelluksella hookien riippuvuuksiin. Opi optimoimaan useEffect, useMemo ja useCallback globaaliin suorituskykyyn.
React-hookien riippuvuuksien hallinta: Tehokkuuden optimointi globaaliin suorituskykyyn
Front-end-kehityksen dynaamisessa maailmassa React on noussut hallitsevaksi voimaksi, joka mahdollistaa monimutkaisten ja interaktiivisten käyttöliittymien rakentamisen. Modernin React-kehityksen ytimessä ovat hookit, voimakas API, jonka avulla voit käyttää tilaa ja muita Reactin ominaisuuksia kirjoittamatta luokkia. Yksi perustavanlaatuisimmista ja useimmin käytetyistä hookeista on useEffect, joka on suunniteltu sivuvaikutusten käsittelyyn funktionaalisissa komponenteissa. Kuitenkin useEffect:n, ja monien muiden hookien, kuten useMemo:n ja useCallback:n, todellinen voima ja tehokkuus riippuvat niiden riippuvuuksien syvällisestä ymmärtämisestä ja oikeasta hallinnasta. Globaalille yleisölle, jossa verkon viive, laitteiden moninaiset kyvykkyydet ja vaihtelevat käyttäjäodotukset ovat ensisijaisia, näiden riippuvuuksien optimointi ei ole vain hyvä käytäntö; se on välttämättömyys sujuvan ja responsiivisen käyttäjäkokemuksen toimittamiseksi.
Ydinkonsepti: Mitä ovat React-hookien riippuvuudet?
Pohjimmiltaan riippuvuustaulukko on lista arvoista (propseista, tilasta tai muuttujista), joihin hook nojaa. Kun jokin näistä arvoista muuttuu, React suorittaa efektin uudelleen tai laskee memoistoidun arvon uudelleen. Toisaalta, jos riippuvuustaulukko on tyhjä ([]), efekti suoritetaan vain kerran ensimmäisen renderöinnin jälkeen, samoin kuin componentDidMount luokkakomponenteissa. Jos riippuvuustaulukko jätetään kokonaan pois, efekti suoritetaan jokaisen renderöinnin jälkeen, mikä voi usein johtaa suorituskykyongelmiin tai äärettömiin silmukoihin.
useEffect-riippuvuuksien ymmärtäminen
useEffect-hookin avulla voit suorittaa sivuvaikutuksia funktionaalisissa komponenteissasi. Näitä sivuvaikutuksia voivat olla datan haku, DOM-manipulaatiot, tilaukset tai DOM:n manuaalinen muuttaminen. useEffect:n toinen argumentti on riippuvuustaulukko. React käyttää tätä taulukkoa määrittääkseen, milloin efekti suoritetaan uudelleen.
Syntaksi:
useEffect(() => {
// Sivuvaikutuslogiikkasi tähän
// Esimerkiksi: datan haku
const fetchData = async () => {
const response = await fetch('https://api.example.com/data');
const data = await response.json();
// päivitä tila datalla
};
fetchData();
// Siivousfunktio (valinnainen)
return () => {
// Siivouslogiikka, esim. tilausten peruuttaminen
};
}, [riippuvuus1, riippuvuus2, ...]);
useEffect-riippuvuuksien avainperiaatteet:
- Sisällytä kaikki efektin sisällä käytetyt reaktiiviset arvot: Jokainen props, tila tai muuttuja, joka on määritelty komponentissasi ja jota luetaan
useEffect-takaisinkutsun sisällä, tulisi sisällyttää riippuvuustaulukkoon. Tämä varmistaa, että efektisi toimii aina uusimmilla arvoilla. - Vältä tarpeettomia riippuvuuksia: Arvojen sisällyttäminen, jotka eivät todellisuudessa vaikuta efektisi lopputulokseen, voi johtaa turhiin suorituskertoihin ja heikentää suorituskykyä.
- Tyhjä riippuvuustaulukko (
[]): Käytä tätä, kun efektin tulisi suorittaa vain kerran ensimmäisen renderöinnin jälkeen. Tämä on ihanteellinen ensimmäiseen datan hakuun tai tapahtumakuuntelijoiden asettamiseen, jotka eivät ole riippuvaisia muuttuvista arvoista. - Ei riippuvuustaulukkoa: Tämä aiheuttaa efektin suorittamisen jokaisen renderöinnin jälkeen. Käytä äärimmäisen varovaisesti, sillä se on yleinen bugien ja suorituskyvyn heikkenemisen lähde, erityisesti globaalisti saatavilla olevissa sovelluksissa, joissa renderöintisyklit voivat olla tiheämpiä.
Yleisiä sudenkuoppia useEffect-riippuvuuksien kanssa
Yksi yleisimmistä kehittäjien kohtaamista ongelmista on puuttuvat riippuvuudet. Jos käytät arvoa efektisi sisällä, mutta et listaa sitä riippuvuustaulukossa, efekti saattaa suorittua vanhentuneen sulkeuman (stale closure) kanssa. Tämä tarkoittaa, että efektin takaisinkutsu saattaa viitata kyseisen riippuvuuden vanhempaan arvoon kuin mikä komponentin tilassa tai propseissa sillä hetkellä on. Tämä on erityisen ongelmallista globaalisti jaetuissa sovelluksissa, joissa verkkokutsut tai asynkroniset operaatiot voivat viedä aikaa, ja vanhentunut arvo voi johtaa virheelliseen toimintaan.
Esimerkki puuttuvasta riippuvuudesta:
function CounterDisplay({ count }) {
const [message, setMessage] = useState('');
useEffect(() => {
// Tämä efekti ei huomioi 'count'-riippuvuutta
// Jos 'count' päivittyy, tämä efekti ei suoritu uudelleen uudella arvolla
const timer = setTimeout(() => {
setMessage(`Nykyinen lukema on: ${count}`);
}, 1000);
return () => clearTimeout(timer);
}, []); // ONGELMA: 'count' puuttuu riippuvuustaulukosta
return {message};
}
Yllä olevassa esimerkissä, jos count-props muuttuu, setTimeout käyttää silti count-arvoa siitä renderöinnistä, jolloin efekti suoritettiin *ensimmäisen* kerran. Korjataksesi tämän, count on lisättävä riippuvuustaulukkoon:
useEffect(() => {
const timer = setTimeout(() => {
setMessage(`Nykyinen lukema on: ${count}`);
}, 1000);
return () => clearTimeout(timer);
}, [count]); // OIKEIN: 'count' on nyt riippuvuus
Toinen sudenkuoppa on äärettömien silmukoiden luominen. Tämä tapahtuu usein, kun efekti päivittää tilaa, ja kyseinen tilan päivitys aiheuttaa uudelleenrenderöinnin, joka sitten laukaisee efektin uudelleen, johtaen kierteeseen.
Esimerkki äärettömästä silmukasta:
function AutoIncrementer() {
const [counter, setCounter] = useState(0);
useEffect(() => {
// Tämä efekti päivittää 'counter'-tilaa, mikä aiheuttaa uudelleenrenderöinnin
// ja sitten efekti suoritetaan uudelleen, koska riippuvuustaulukkoa ei ole annettu
setCounter(prevCounter => prevCounter + 1);
}); // ONGELMA: Ei riippuvuustaulukkoa, tai 'counter' puuttuisi, jos se olisi siellä
return Laskuri: {counter};
}
Silmukan katkaisemiseksi sinun on joko annettava sopiva riippuvuustaulukko (jos efekti riippuu jostakin tietystä) tai hallittava päivityslogiikkaa huolellisemmin. Esimerkiksi, jos haluat sen kasvavan vain kerran, käyttäisit tyhjää riippuvuustaulukkoa ja ehtoa, tai jos sen on tarkoitus kasvaa jonkin ulkoisen tekijän perusteella, sisällytä kyseinen tekijä.
useMemo- ja useCallback-riippuvuuksien hyödyntäminen
Vaikka useEffect on tarkoitettu sivuvaikutuksiin, useMemo ja useCallback ovat suorituskyvyn optimointeja, jotka liittyvät memoisaatioon.
useMemo: Memoistoi funktion tuloksen. Se laskee arvon uudelleen vain, kun jokin sen riippuvuuksista muuttuu. Tämä on hyödyllistä kalliille laskutoimituksille.useCallback: Memoistoi itse takaisinkutsufunktion. Se palauttaa saman funktioinstanssin renderöintien välillä niin kauan kuin sen riippuvuudet eivät ole muuttuneet. Tämä on ratkaisevan tärkeää estämään tarpeettomia uudelleenrenderöintejä lapsikomponenteissa, jotka luottavat propsien viitteelliseen tasa-arvoon.
Sekä useMemo että useCallback hyväksyvät myös riippuvuustaulukon, ja säännöt ovat identtiset useEffect:n kanssa: sisällytä kaikki komponentin laajuudesta peräisin olevat arvot, joihin memoistoitu funktio tai arvo nojaa.
Esimerkki useCallback:lla:
function ParentComponent() {
const [count, setCount] = useState(0);
const [otherState, setOtherState] = useState(false);
// Ilman useCallbackia handleClick olisi uusi funktio jokaisella renderöinnillä,
// aiheuttaen lapsikomponentti MyButtonin tarpeettoman uudelleenrenderöinnin.
const handleClick = useCallback(() => {
console.log(`Nykyinen lukema on: ${count}`);
// Tee jotain count-arvolla
}, [count]); // Riippuvuus: 'count' varmistaa, että takaisinkutsu päivittyy, kun 'count' muuttuu.
return (
Lukema: {count}
Tässä skenaariossa, jos otherState muuttuu, ParentComponent renderöityy uudelleen. Koska handleClick on memoistoitu useCallback:lla ja sen riippuvuus (count) ei ole muuttunut, sama handleClick-funktioinstanssi välitetään MyButton-komponentille. Jos MyButton on kääritty React.memo:on, se ei renderöidy tarpeettomasti uudelleen.
Esimerkki useMemo:lla:
function DataDisplay({ items }) {
// Kuvitellaan, että 'processItems' on kallis operaatio
const processedItems = useMemo(() => {
console.log('Käsitellään kohteita...');
return items.filter(item => item.isActive).map(item => item.name.toUpperCase());
}, [items]); // Riippuvuus: 'items'-taulukko
return (
{processedItems.map((item, index) => (
- {item}
))}
);
}
processedItems-taulukko lasketaan uudelleen vain, jos items-props itsessään muuttuu (viitteellinen tasa-arvo). Jos komponentin muu tila muuttuu aiheuttaen uudelleenrenderöinnin, items-taulukon kallis käsittely ohitetaan.
Globaalit näkökohdat hookien riippuvuuksille
Kun rakennetaan sovelluksia globaalille yleisölle, useat tekijät korostavat hookien riippuvuuksien oikeanlaisen hallinnan tärkeyttä:
1. Verkon viive ja asynkroniset operaatiot
Käyttäjät, jotka käyttävät sovellustasi eri maantieteellisistä sijainneista, kokevat vaihtelevia verkkonopeuksia. Datan haku useEffect:n sisällä on erinomainen optimointikohde. Virheellisesti hallitut riippuvuudet voivat johtaa:
- Liialliseen datan hakuun: Jos efekti suoritetaan tarpeettomasti puuttuvan tai liian laajan riippuvuuden vuoksi, se voi johtaa turhiin API-kutsuhin, kuluttaen kaistanleveyttä ja palvelinresursseja tarpeettomasti.
- Vanhentuneen datan näyttämiseen: Kuten mainittu, vanhentuneet sulkeumat voivat aiheuttaa sen, että efektit käyttävät vanhentunutta dataa, mikä johtaa epäjohdonmukaiseen käyttäjäkokemukseen, erityisesti jos efekti laukeaa käyttäjän vuorovaikutuksesta tai tilanmuutoksista, joiden pitäisi näkyä välittömästi.
Globaali paras käytäntö: Ole tarkka riippuvuuksiesi kanssa. Jos efekti hakee dataa ID:n perusteella, varmista, että ID on riippuvuustaulukossa. Jos datan haku tulisi tapahtua vain kerran, käytä tyhjää taulukkoa.
2. Vaihtelevat laiteominaisuudet ja suorituskyky
Käyttäjät saattavat käyttää sovellustasi huippuluokan pöytäkoneilla, keskitason kannettavilla tai heikompitehoisilla mobiililaitteilla. Tehottomat renderöinnit tai liialliset laskutoimitukset, jotka johtuvat optimoimattomista hookeista, voivat vaikuttaa suhteettoman paljon käyttäjiin, joilla on heikompi laitteisto.
- Kalliit laskutoimitukset: Raskaat laskutoimitukset
useMemo:ssa tai suoraan renderöinnissä voivat jäädyttää käyttöliittymiä hitaammilla laitteilla. - Tarpeettomat uudelleenrenderöinnit: Jos lapsikomponentit renderöityvät uudelleen virheellisen propsien käsittelyn vuoksi (usein liittyen
useCallback:in puuttuviin riippuvuuksiin), se voi hidastaa sovellusta millä tahansa laitteella, mutta se on huomattavinta heikompitehoisilla laitteilla.
Globaali paras käytäntö: Käytä useMemo:ta laskennallisesti kalliisiin operaatioihin ja useCallback:ia vakauttamaan lapsikomponenteille välitettäviä funktio-viittauksia. Varmista, että niiden riippuvuudet ovat tarkkoja.
3. Kansainvälistäminen (i18n) ja lokalisointi (l10n)
Useita kieliä tukevissa sovelluksissa on usein dynaamisia arvoja, jotka liittyvät käännöksiin, muotoiluihin tai lokaaliasetuksiin. Nämä arvot ovat erinomaisia ehdokkaita riippuvuuksiksi.
- Käännösten haku: Jos efektisi hakee käännöstiedostoja valitun kielen perusteella, kielikoodin *täytyy* olla riippuvuus.
- Päivämäärien ja numeroiden muotoilu: Kirjastot kuten
Intltai erikoistuneet kansainvälistämiskirjastot saattavat nojata lokaalitietoihin. Jos tämä tieto on reaktiivista (esim. käyttäjä voi muuttaa sitä), sen tulisi olla riippuvuus kaikille efekteille tai memoistoiduille arvoille, jotka käyttävät sitä.
Esimerkki i18n:n kanssa:
import { useTranslation } from 'react-i18next';
import { formatDistanceToNow } from 'date-fns';
function RecentActivity({ timestamp }) {
const { i18n } = useTranslation();
// Päivämäärän muotoilu suhteessa nykyhetkeen, tarvitsee lokaalin ja aikaleiman
const formattedTime = useMemo(() => {
// Olettaen, että date-fns on konfiguroitu käyttämään nykyistä i18n-lokaalia
// tai välitämme sen eksplisiittisesti:
// formatDistanceToNow(new Date(timestamp), { addSuffix: true, locale: i18n.locale })
console.log('Muotoillaan päivämäärää...');
return formatDistanceToNow(new Date(timestamp), { addSuffix: true });
}, [timestamp, i18n.language]); // Riippuvuudet: aikaleima ja nykyinen kieli
return Viimeksi päivitetty: {formattedTime}
;
}
Tässä, jos käyttäjä vaihtaa sovelluksen kieltä, i18n.language muuttuu, mikä laukaisee useMemo:n laskemaan muotoillun ajan uudelleen oikealla kielellä ja mahdollisesti eri käytänteillä.
4. Tilanhallinta ja globaalit storet
Monimutkaisissa sovelluksissa tilanhallintakirjastot (kuten Redux, Zustand, Jotai) ovat yleisiä. Näistä globaaleista storeista johdetut arvot ovat reaktiivisia, ja niitä tulee käsitellä riippuvuuksina.
- Storen päivitysten tilaaminen: Jos
useEffecttilaa muutoksia globaalista storesta tai hakee dataa storesta peräisin olevan arvon perusteella, kyseinen arvo on sisällytettävä riippuvuustaulukkoon.
Esimerkki hypoteettisella globaalilla store-hookilla:
// Olettaen, että useAuth() palauttaa { user, isAuthenticated }
function UserGreeting() {
const { user, isAuthenticated } = useAuth();
useEffect(() => {
if (isAuthenticated && user) {
console.log(`Tervetuloa takaisin, ${user.name}! Haetaan käyttäjäasetuksia...`);
// Hae käyttäjäasetukset user.id:n perusteella
fetchUserPreferences(user.id).then(prefs => {
// päivitä paikallista tilaa tai toista storea
});
} else {
console.log('Kirjaudu sisään.');
}
}, [isAuthenticated, user]); // Riippuvuudet: tila auth-storesta
return (
{isAuthenticated ? `Hei, ${user.name}` : 'Kirjaudu sisään'}
);
}
Tämä efekti suoritetaan oikeaoppisesti uudelleen vain, kun autentikointitila tai käyttäjäobjekti muuttuu, estäen tarpeettomia API-kutsuja tai lokeja.
Edistyneitä riippuvuuksien hallintastrategioita
1. Kustomoidut hookit uudelleenkäytettävyyteen ja kapselointiin
Kustomoidut hookit ovat erinomainen tapa kapseloida logiikkaa, mukaan lukien efektit ja niiden riippuvuudet. Tämä edistää uudelleenkäytettävyyttä ja tekee riippuvuuksien hallinnasta järjestelmällisempää.
Esimerkki: Kustomoitu hook datan hakuun
import { useState, useEffect } from 'react';
function useFetchData(url, options = {}) {
const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);
// Käytä JSON.stringify-metodia monimutkaisille objekteille riippuvuuksissa, mutta ole varovainen.
// Yksinkertaisille arvoille, kuten URL-osoitteille, se on suoraviivaista.
const stringifiedOptions = JSON.stringify(options);
useEffect(() => {
const fetchData = async () => {
setLoading(true);
setError(null);
try {
const response = await fetch(url, JSON.parse(stringifiedOptions));
if (!response.ok) {
throw new Error(`HTTP-virhe! status: ${response.status}`);
}
const result = await response.json();
setData(result);
} catch (err) {
setError(err);
} finally {
setLoading(false);
}
};
// Hae vain, jos URL on annettu ja validi
if (url) {
fetchData();
} else {
// Käsittele tapaus, jossa URL ei ole aluksi saatavilla
setLoading(false);
}
// Siivousfunktio hakupyyntöjen keskeyttämiseksi, jos komponentti poistetaan tai riippuvuudet muuttuvat
// Huom: AbortController on vankempi tapa käsitellä tämä modernissa JS:ssä
const abortController = new AbortController();
const signal = abortController.signal;
// Muokkaa fetch-kutsua käyttämään signaalia
// fetch(url, { ...JSON.parse(stringifiedOptions), signal })
return () => {
abortController.abort(); // Keskeytä meneillään oleva hakupyyntö
};
}, [url, stringifiedOptions]); // Riippuvuudet: url ja merkkijonoksi muutetut optiot
return { data, loading, error };
}
// Käyttö komponentissa:
function UserProfile({ userId }) {
const { data: user, loading, error } = useFetchData(
userId ? `/api/users/${userId}` : null,
{ method: 'GET' } // Optio-objekti
);
if (loading) return Ladataan käyttäjäprofiilia...
;
if (error) return Virhe profiilin lataamisessa: {error.message}
;
if (!user) return Valitse käyttäjä.
;
return (
{user.name}
Sähköposti: {user.email}
);
}
Tässä kustomoidussa hookissa url ja stringifiedOptions ovat riippuvuuksia. Jos userId muuttuu UserProfile-komponentissa, url muuttuu, ja useFetchData hakee automaattisesti uuden käyttäjän tiedot.
2. Ei-sarjallistettavien riippuvuuksien käsittely
Joskus riippuvuudet voivat olla objekteja tai funktioita, jotka eivät sarjallistu hyvin tai joiden viite muuttuu jokaisella renderöinnillä (esim. inline-funktiomääritykset ilman useCallback:ia). Monimutkaisten objektien kohdalla varmista, että niiden identiteetti on vakaa tai että vertaat oikeita ominaisuuksia.
JSON.stringify:n käyttö varoen: Kuten kustomoidun hookin esimerkissä nähtiin, JSON.stringify voi sarjallistaa objekteja käytettäväksi riippuvuuksina. Tämä voi kuitenkin olla tehotonta suurille objekteille eikä ota huomioon objektin mutaatiota. On yleensä parempi sisällyttää objektin tietyt, vakaat ominaisuudet riippuvuuksiksi, jos mahdollista.
Viitteellinen tasa-arvo: Propseina välitetyille tai kontekstista johdetuille funktioille ja objekteille viitteellisen tasa-arvon varmistaminen on avainasemassa. useCallback ja useMemo auttavat tässä. Jos saat objektin kontekstista tai tilanhallintakirjastosta, se on yleensä vakaa, ellei sen taustalla oleva data muutu.
3. Linter-sääntö (eslint-plugin-react-hooks)
React-tiimi tarjoaa ESLint-lisäosan, joka sisältää säännön nimeltä exhaustive-deps. Tämä sääntö on korvaamaton puuttuvien riippuvuuksien automaattisessa havaitsemisessa useEffect:ssä, useMemo:ssa ja useCallback:ssa.
Säännön käyttöönotto:
Jos käytät Create React App -sovellusta, tämä lisäosa on yleensä mukana oletuksena. Jos pystytät projektin manuaalisesti, varmista, että se on asennettu ja konfiguroitu ESLint-asetuksissasi:
npm install --save-dev eslint-plugin-react-hooks
# tai
yarn add --dev eslint-plugin-react-hooks
Lisää .eslintrc.js- tai .eslintrc.json-tiedostoosi:
{
"plugins": [
"react-hooks"
],
"rules": {
"react-hooks/rules-of-hooks": "error",
"react-hooks/exhaustive-deps": "warn" // Tai 'error'
}
}
Tämä sääntö ilmoittaa puuttuvista riippuvuuksista ja auttaa sinua nappaamaan mahdolliset vanhentuneiden sulkeumien ongelmat ennen kuin ne vaikuttavat globaaliin käyttäjäkuntaasi.
4. Efektien rakentaminen luettavuuden ja ylläpidettävyyden parantamiseksi
Sovelluksesi kasvaessa myös efektiesi monimutkaisuus kasvaa. Harkitse näitä strategioita:
- Pilko monimutkaiset efektit: Jos efekti suorittaa useita erillisiä tehtäviä, harkitse sen jakamista useisiin
useEffect-kutsuihin, joilla kullakin on omat kohdennetut riippuvuutensa. - Erota vastuualueet: Käytä kustomoituja hookeja kapseloidaksesi tiettyjä toiminnallisuuksia (esim. datan haku, lokitus, DOM-manipulaatio).
- Selkeä nimeäminen: Nimeä riippuvuutesi ja muuttujasi kuvaavasti, jotta efektin tarkoitus on ilmeinen.
Yhteenveto: Optimointi yhteydessä olevaan maailmaan
React-hookien riippuvuuksien hallinta on kriittinen taito jokaiselle kehittäjälle, mutta se saa entistä suuremman merkityksen, kun rakennetaan sovelluksia globaalille yleisölle. Hallitsemalla huolellisesti useEffect:n, useMemo:n ja useCallback:n riippuvuustaulukoita varmistat, että efektisi suoritetaan vain tarvittaessa, estäen suorituskyvyn pullonkauloja, vanhentuneen datan ongelmia ja tarpeettomia laskutoimituksia.
Kansainvälisille käyttäjille tämä tarkoittaa nopeampia latausaikoja, responsiivisempaa käyttöliittymää ja johdonmukaista kokemusta riippumatta heidän verkkoyhteyksistään tai laiteominaisuuksistaan. Ota käyttöön exhaustive-deps-sääntö, hyödynnä kustomoituja hookeja puhtaamman logiikan saavuttamiseksi ja mieti aina riippuvuuksiesi vaikutuksia palvelemaasi monimuotoiseen käyttäjäkuntaan. Oikein optimoidut hookit ovat tehokkaiden, globaalisti saatavilla olevien React-sovellusten perusta.
Toiminnallisia oivalluksia:
- Tarkasta efektisi: Käy säännöllisesti läpi
useEffect-,useMemo- jauseCallback-kutsusi. Ovatko kaikki käytetyt arvot riippuvuustaulukossa? Onko siellä tarpeettomia riippuvuuksia? - Käytä linteriä: Varmista, että
exhaustive-deps-sääntö on aktiivinen ja sitä noudatetaan projektissasi. - Refaktoroi kustomoiduilla hookeilla: Jos huomaat toistavasi efektilogiikkaa samankaltaisilla riippuvuusmalleilla, harkitse kustomoidun hookin luomista.
- Testaa simuloiduissa olosuhteissa: Käytä selaimen kehittäjätyökaluja simuloidaksesi hitaampia verkkoja ja heikompitehoisia laitteita suorituskykyongelmien tunnistamiseksi ajoissa.
- Priorisoi selkeyttä: Kirjoita efektisi ja niiden riippuvuudet tavalla, joka on helppo muiden kehittäjien (ja tulevan itsesi) ymmärtää.
Noudattamalla näitä periaatteita voit rakentaa React-sovelluksia, jotka eivät ainoastaan täytä, vaan ylittävät käyttäjien odotukset maailmanlaajuisesti, tarjoten todella globaalin ja suorituskykyisen kokemuksen.