Prop-boring i React: Ulemper og alternativer

Prop-boring i React: Ulemper og alternativer
Læsere som dig hjælper med at støtte MUO. Når du foretager et køb ved hjælp af links på vores websted, kan vi optjene en affiliate-kommission. Læs mere.

Håndtering af data og opbygning af stærke, vedligeholdelige applikationer er vitale færdigheder i softwareudvikling. En almindelig måde at modularisere dine React-apps på er at bruge prop-boring, som hjælper med at sende data ned i komponenttræet.





MUO video af dagen RUL FOR AT FORTSÆTTE MED INDHOLD

Men efterhånden som projekterne bliver større, kan propboring have sine ulemper. Udforsk problemerne omkring propboring og find ud af, hvilke alternativer der er tilgængelige.



Forståelse af propboring

Propboring er en teknik, der sender data ned i komponenttræet som rekvisitter, uanset om mellemkomponenterne har brug for dataene eller ej.





Boring involverer at overføre rekvisitter fra en forælder til dens underordnede komponenter og længere nede i hierarkiet. Hovedmålet er at gøre det muligt for komponenter på lavere niveauer af træet at få adgang til og bruge data, som komponenter på højere niveau leverer.

En diagrammatisk fremstilling af, hvordan propboring fungerer

Ulemperne ved propboring

Mens propboring løser problemet med at dele data, introducerer det adskillige ulemper, der kan hindre kodevedligeholdelse og udviklingseffektivitet.



kan ikke slette fil i brug

1. Øget kompleksitet

Efterhånden som en applikation vokser, bliver propboring sværere at styre. Dette kan føre til et komplekst net af komponentafhængigheder, hvilket gør koden svær at forstå og ændre.

 import ChildComponent from './ChildComponent'; 
 
export default function ParentComponent = () => {  
  const data = 'Prop drilling!';  
  return ( <div> <ChildComponent data={data} /> </div> ); 
}; 
 
import GrandChildComponent from './GrandChildComponent';  
 
export default function ChildComponent = ({ data }) => { 
  return ( <div> <GrandChildComponent data={data} /> </div> ); 
}; 
 
import GreatGrandChildComponent from './GreatGrandChildComponent';  
 
export default function GrandChildComponent = ({ data }) => {  
  return ( <div> <GreatGrandChildComponent data={data} /> </div> ); 
}; 
 
export default function GreatGrandChildComponent = ({ data }) => {  
  return ( <div> <p>{data}</p> </div> ); 
};

Her flyttes data fra ParentComponent på øverste niveau til GreatGrandChildComponent gennem to mellemliggende komponenter.



Efterhånden som komponenthierarkiet vokser dybere, og flere komponenter er afhængige af støtten, bliver det sværere at spore og administrere dataflow.

2. Tæt kobling

Dette sker, når komponenter er afhængige af hinanden via rekvisitter, hvilket gør det svært at ændre eller genbruge dem. Dette kan gøre det vanskeligt at foretage ændringer i én komponent uden at påvirke de andre.



 import ChildComponentA from './ChildComponentA';  
import ChildComponentB from './ChildComponentB'; 
 
export default function ParentComponent = () => {  
  const sharedData = 'Shared data';  
 
 return (  
    <div> 
     <ChildComponentA data={sharedData} /> 
     <ChildComponentB data={sharedData} />  
    </div> 
 ); 
}; 
 
import GrandChildComponent from './GrandChildComponent';  
 
export default function ChildComponentA = ({ data }) => {  
  return ( 
   <div> 
     <p>Component A</p> 
     <GrandChildComponent data={data} />  
    </div> 
 ); 
}; 
 
import GrandChildComponent from './GrandChildComponent';  
 
export default function ChildComponentB = ({ data }) => {  
  return ( 
   <div> 
     <p>Component B</p> 
     <GrandChildComponent data={data} />  
    </div> 
 ); 
}; 
 
export default function GrandChildComponent = ({ data }) => {  
  return (  
    <div> <p>{data}</p> </div> 
 ); 
};

Her modtager begge underordnede komponenter de samme data fra deres overordnede komponent og videregiver dem til GrandChildComponent.

Hvis dataene bliver opdateret, skal alle komponenter i hierarkiet også opdateres, selvom nogle ikke bruger dataene. Dette kan være svært og tidskrævende, og det øger også risikoen for at introducere fejl.

3. Kodevedligeholdelse

Støtteboring er et kodevedligeholdelsesproblem, fordi nye komponenter skal have adgang til rekvisitter, der føres gennem hierarkiet. Dette kan føre til fejl, hvis du har brug for at ændre mange komponenter, og uoverensstemmelser, hvis rekvisitter ændres.

 import ChildComponent from './ChildComponent';  
 
export default function ParentComponent = () => {  
  const [count, setCount] = useState(0);  
 
  const incrementCount = () => { 
    setCount(count + 1); 
  }; 
 
  return (  
    <div> 
     <ChildComponent count={count} incrementCount={incrementCount} />  
    </div> 
 ); 
}; 
 
import GrandChildComponent from './GrandChildComponent';  
 
export default function ChildComponent = ({ count, incrementCount }) => {  
  return (  
    <div>  
      <button onClick={incrementCount}>Increment</button>  
      <GrandChildComponent count={count} />  
    </div> 
 ); 
}; 
 
export default function GrandChildComponent = ({ count }) => {  
  return (  
    <div> 
      <p>Count: {count}</p> 
   </div> 
 ); 
};

Her sender ParentComponent tælleværdien som en prop til ChildComponent og derefter til GrandChildComponent.

Men hvis antallet ændres, eller hvis der er en ny regel for at sende ekstra rekvisitter, bliver du nødt til at opdatere hver komponent i hierarkiet, der bruger rekvisitterne. Denne proces er udsat for fejl, hvilket gør kodevedligeholdelse svær og øger uoverensstemmelser eller fejl.

hvorfor fungerer min proceslinje ikke windows 10

Udforskning af alternativer til propboring

Der er mange statsforvaltningsløsninger i React-økosystemet, som du kan bruge til at overvinde ulemperne ved propboring.

Reager kontekst

React Context er en funktion, der muliggør deling af tilstand på tværs af komponenter uden at bestå rekvisitter. Det giver et centraliseret lager, som komponenter kan få adgang til med useContext hook . Dette kan forbedre ydeevnen og gøre det nemmere at administrere tilstanden.

Et rutediagram, der viser React Context, der leverer data til alle komponenter i en applikation

Redux

Redux er et statsadministrationsbibliotek, der giver en enkelt global statsbutik. Komponenter kan få adgang til og opdatere tilstanden gennem handlinger og reducering. Dette kan hjælpe med at holde din kode organiseret og kan gøre det lettere at fejlfinde.

kan en mindreårig have en PayPal -konto
Et rutediagram, der viser Redux, der leverer data til alle komponenter i en applikation

MobX

MobX er et statsforvaltningsbibliotek, der bruger observerbare data. Det betyder, at komponenter kan abonnere på ændringer i staten og handle som reaktion. Biblioteket kan gøre din kode mere reaktiv og kan forbedre ydeevnen.

Et flowdiagram, der viser flere MobX-koncepter og -handlinger, og hvordan de forbindes med hinanden

Noget

Jotai er et statsforvaltningsbibliotek for React , der bruger en atomtilstandsmodel. Det giver dig mulighed for at oprette tilstandsatomer, som komponenter kan få adgang til og opdatere.

Med Jotai kan du reducere behovet for propboring og opnå en mere strømlinet og effektiv statsforvaltningstilgang. Dets minimalistiske design og fokus på ydeevne gør det til et overbevisende valg til styring af tilstand i React-applikationer.

Et flowdiagram, der viser flere Jotai-koncepter og -handlinger, og hvordan de forbindes med hinanden

Mestring af komponentkommunikation: Udvid din værktøjskasse ud over propboring

Prop-boring er en teknik til at overføre data fra overordnede komponenter til underordnede komponenter. Det er effektivt til at dele data, men det har flere ulemper, der kan gøre kode svær at vedligeholde og udvikle.

For at overvinde disse ulemper kan du bruge alternativer som React Context, Redux og MobX. Disse løsninger giver en mere centraliseret måde at administrere data på, hvilket kan gøre koden mere vedligeholdelsesvenlig og skalerbar.