Tugipuurimine võib olla kasulik nipp, kuid peate jälgima mõningaid ebamugavaid lõkse.
Andmete haldamine ja tugevate, hooldatavate rakenduste loomine on olulised tarkvaraarenduse oskused. Levinud viis Reacti rakenduste moduleerimiseks on kasutada tugipuurimist, mis aitab andmeid komponentide puusse edastada.
Kuid kui projektid muutuvad suuremaks, võib rekvisiitide puurimisel olla oma puudusi. Uurige rekvisiitide puurimisega seotud probleeme ja uurige, millised alternatiivid on saadaval.
Prop puurimise mõistmine
Prop puurimine on tehnika, mis edastab andmed komponentide puusse rekvisiididena, olenemata sellest, kas vahekomponendid vajavad andmeid või mitte.
Puurimine hõlmab rekvisiitide edastamist vanemalt selle alamkomponentidele ja hierarhias allapoole. Peamine eesmärk on võimaldada puu madalamatel tasanditel asuvatel komponentidel juurdepääs andmetele, mida kõrgema taseme komponendid pakuvad, ja neid kasutada.
Prop puurimise miinused
Kuigi tugipuurimine lahendab andmete jagamise probleemi, toob see kaasa mitmeid puudusi, mis võivad takistada koodi hooldatavust ja arenduse tõhusust.
1. Suurenenud keerukus
Rakenduse kasvades muutub rekvisiitide puurimine keerulisemaks. See võib kaasa tuua keeruka komponentide sõltuvuste võrgu, mis muudab koodi raskesti mõistetavaks ja muutmiseks keeruliseks.
import ChildComponent from'./ChildComponent';
exportdefaultfunctionParentComponent = () => {
const data = 'Prop drilling!';
return ( <div><ChildComponentdata={data} />div> );
};import GrandChildComponent from'./GrandChildComponent';
exportdefaultfunctionChildComponent = ({ data }) => {
return ( <div><GrandChildComponentdata={data} />div> );
};import GreatGrandChildComponent from'./GreatGrandChildComponent';
exportdefaultfunctionGrandChildComponent = ({ data }) => {
return ( <div><GreatGrandChildComponentdata={data} />div> );
};
exportdefaultfunctionGreatGrandChildComponent = ({ data }) => {
return ( <div><p>{data}p>div> );
};
Siin liiguvad andmed tipptasemel ParentComponentist kahe vahekomponendi kaudu GreatGrandChildComponenti.
Kuna komponentide hierarhia süveneb ja rohkem komponente tugineb rekvisiidile, on andmevoogu raskem jälgida ja hallata.
2. Tihe ühendus
See juhtub siis, kui komponendid sõltuvad üksteisest rekvisiitide kaudu, mistõttu on nende muutmine või taaskasutamine raskendatud. See võib raskendada ühe komponendi muutmist ilma teisi mõjutamata.
import ChildComponentA from'./ChildComponentA';
import ChildComponentB from'./ChildComponentB';exportdefaultfunctionParentComponent = () => {
const sharedData = 'Shared data';
return (
</div>
);
};
import GrandChildComponent from'./GrandChildComponent';
exportdefaultfunctionChildComponentA = ({ data }) => {
return (
Component A</p>
</div>
);
};
import GrandChildComponent from'./GrandChildComponent';
exportdefaultfunctionChildComponentB = ({ data }) => {
return (
Component B</p>
</div>
);
};
exportdefaultfunctionGrandChildComponent = ({ data }) => {
return (
<p>{data}p> </div>
);
};
Siin saavad mõlemad alamkomponendid oma emakomponendilt samad andmed ja edastavad need GrandChildComponentile.
Kui andmeid värskendatakse, vajavad värskendamist ka kõik hierarhia komponendid, isegi kui mõned neist andmeid ei kasuta. See võib olla keeruline ja aeganõudev ning suurendab ka vigade sissetoomise ohtu.
3. Koodi hooldatavus
Prop puurimine on koodi hooldusprobleem, kuna uued komponendid vajavad juurdepääsu hierarhiast läbitud rekvisiitidele. See võib põhjustada vigu, kui peate muutma paljusid komponente, ja ebakõlasid, kui rekvisiidid muutuvad.
import ChildComponent from'./ChildComponent';
exportdefaultfunctionParentComponent = () => {
const [count, setCount] = useState(0);const incrementCount = () => {
setCount(count + 1);
};return (
</div>
);
};import GrandChildComponent from'./GrandChildComponent';
exportdefaultfunctionChildComponent = ({ count, incrementCount }) => {
return (
exportdefaultfunctionGrandChildComponent = ({ count }) => {
return (Count: {count}</p>
</div>
);
};
Siin edastab ParentComponent loendusväärtuse tugikomponendina ChildComponentile ja seejärel GrandChildComponentile.
Kui aga arv muutub või kui on olemas uus reegel täiendavate rekvisiitide edastamiseks, peate värskendama iga rekvisiidi kasutavat komponenti hierarhias. See protsess on veatundlik, muutes koodi hooldamise keeruliseks ja suurendades ebakõlasid või vigu.
Prop puurimise alternatiivide uurimine
Reacti ökosüsteemis on palju riigihalduslahendusi, mida saate kasutada rekvisiitide puurimise puuduste ületamiseks.
Reaktsiooni kontekst
React Context on funktsioon, mis võimaldab jagada olekut komponentide vahel ilma rekvisiite edastamata. See pakub tsentraliseeritud poodi, millele komponentidele juurde pääseb konksuga useContext. See võib parandada jõudlust ja hõlbustada oleku haldamist.
Redux
Redux on olekuhalduse raamatukogu, mis pakub ühtset globaalset olekuteavet. Komponendid saavad olekule juurde pääseda ja seda värskendada toimingute ja reduktorite kaudu. See võib aidata teie koodi korras hoida ja hõlbustada silumist.
MobX
MobX on olekuhalduse raamatukogu, mis kasutab jälgitavaid andmeid. See tähendab, et komponendid saavad liituda olekumuutustega ja reageerida sellele. Teek võib muuta teie koodi reaktiivsemaks ja parandada jõudlust.
Jotai
Jotai on Reacti riigihalduse raamatukogu, mis kasutab aatomi oleku mudelit. See võimaldab teil luua olekuaatomeid, millele komponendid pääsevad juurde ja mida värskendada.
Jotai abil saate vähendada rekvisiitide puurimise vajadust ja saavutada sujuvama ja tõhusama riigijuhtimise lähenemisviisi. Selle minimalistlik disain ja keskendumine jõudlusele muudavad selle mõjuvaks valikuks Reacti rakenduste oleku haldamiseks.
Prop drilling on meetod andmete edastamiseks põhikomponentidelt alamkomponentidele. See on tõhus andmete jagamiseks, kuid sellel on mitmeid puudusi, mis võivad muuta koodi hooldamise ja arendamise keeruliseks.
Nende puuduste ületamiseks võite kasutada selliseid alternatiive nagu React Context, Redux ja MobX. Need lahendused pakuvad tsentraliseeritud viisi andmete haldamiseks, mis võib muuta koodi paremini hooldatavaks ja skaleeritavamaks.