Als je al een tijdje met React werkt, ben je waarschijnlijk tegengekomen houder en presentatiecomponenten , of slimme en domme componenten. Deze termen beschrijven een patroon die de UI-laag van React-componenten scheidt van de logica.
Het scheiden van de gebruikersinterface van de bedrijfslogica is niet uniek voor React: het scheiden van zorgen is een ontwerpprincipe dat: bestond al in de jaren 70. Het is bijvoorbeeld gebruikelijk om de code die toegang heeft tot de database te scheiden van de bedrijfslogica op de backend.
Dus in React hebben we dit probleem opgelost door containercomponenten te maken die alle logica bevatten, die vervolgens de gegevens via rekwisieten zouden doorgeven aan de presentatiecomponent.
Met de introductie van React hooks is er een nieuwe benadering hiervoor: het gebruik van aangepaste haken.
Waarom moeten we de logica van de component scheiden?
Voordat we beginnen met het ontkoppelen van de logica van onze React-componenten, moeten we weten waarom.
Het organiseren van onze code op een manier waarbij elke functie of component maar voor één ding verantwoordelijk is, heeft het voordeel dat het veel is gemakkelijker te veranderen en te onderhouden (Dave en Andrew noemen dit “orthogonaliteit” in hun boek De pragmatische programmeur).
Door dit toe te passen op React, ziet ons onderdeel er schoner en overzichtelijker uit. We hoeven bijvoorbeeld niet langs de muur van logica te scrollen voordat we de gebruikersinterface bewerken.
Als u uw code op deze manier organiseert, ziet deze er niet alleen beter uit en is het gemakkelijker om te navigeren, maar het maakt het ook gemakkelijker om te veranderen, omdat het veranderen van de haak geen invloed heeft op de gebruikersinterface en vice versa.
Testen is ook toegankelijker: we kunnen de logica los van de gebruikersinterface testen als we dat willen. Het belangrijkste voordeel voor mij is echter hoe deze aanpak mijn code organiseert.
Logica ontkoppelen met React hooks
Om de logica van onze component te ontkoppelen, zullen we eerst een aangepaste hook maken.
Laten we dit onderdeel als voorbeeld nemen. Het berekent de exponentiële waarde van het grondtal en de exponent:
U kunt de volledige broncode vinden hier.
De code ziet er als volgt uit:
export const ExponentCalculator = () => {
const [base, setBase] = useState(4);
const [exponent, setExponent] = useState(4);
const result = (base ** exponent).toFixed(2);
const handleBaseChange = (e) => {
e.preventDefault();
setBase(e.target.value);
};
const handleExponentChange = (e) => {
e.preventDefault();
setExponent(e.target.value);
};
return (
<div className="blue-wrapper">
<input
type="number"
className="base"
onChange={handleBaseChange}
placeholder="Base"
value={base}
/>
<input
type="number"
className="exponent"
onChange={handleExponentChange}
placeholder="Exp."
value={exponent}
/>
<h1 className="result">{result}</h1>
</div>
);
};
Dit ziet er misschien al goed uit, maar omwille van deze tutorial, gewoon beeld dat hier meer logica in zit.
Als eerste stap zullen we verplaats de logica naar een aangepaste haak en noem het binnen onze component.
const useExponentCalculator = () => {
const [base, setBase] = useState(4);
const [exponent, setExponent] = useState(4);
const result = (base ** exponent).toFixed(2);
const handleBaseChange = (e) => {
e.preventDefault();
setBase(e.target.value);
};
const handleExponentChange = (e) => {
e.preventDefault();
setExponent(e.target.value);
};
return {
base,
exponent,
result,
handleBaseChange,
handleExponentChange,
};
};
export const ExponentCalculator = () => {
const {
base,
exponent,
result,
handleExponentChange,
handleBaseChange,
} = useExponentCalculator();
// ...
};
We zouden deze haak kunnen verplaatsen naar een apart bestand voor een meer prominente scheiding van zorgen.
Bovendien kunnen we onze haak verder opsplitsen in kleinere, herbruikbare functies. In dit geval kunnen we alleen extraheren: calculateExponent.
gebruikExponentCalculator.js
const calculateExponent = (base, exponent) => base ** exponent;
const useExponentCalculator = () => {
const [base, setBase] = useState(4);
const [exponent, setExponent] = useState(4);
const result = calculateExponent(base, exponent).toFixed(2);
// ...
};
Het testen van deze functies is veel eenvoudiger dan het testen van de code van het volledige onderdeel uit het eerste voorbeeld. We zouden ze kunnen testen met elke Node.js-testbibliotheek, die zelfs geen React-componenten hoeft te ondersteunen.
We hebben nu onze framework-specifieke code (React) in de code voor de component en de hook, terwijl onze bedrijfslogica leeft in de verschillende functies die we later hebben gedefinieerd (die framework-agnostisch zijn).
Beste praktijken
Benoemen
Ik noem mijn aangepaste haken graag naar het onderdeel als een aaneenschakeling van use en de naam van het onderdeel (bijv useExponentCalculator). Ik bel dan de hetzelfde bestand als de haak.
Misschien wil je een andere naamgevingsconventie volgen, maar ik raad aan: consistent blijven bij uw project.
Als ik delen van een aangepaste hook kan hergebruiken, verplaats ik het meestal naar een ander bestand onder src/hooks.
Overdrijf het niet
Probeer pragmatisch te zijn. Als een component maar een paar regels JS heeft, is het niet nodig om de logica te scheiden.
CSS-in-JS
Als u een CSS-in-JS-bibliotheek gebruikt (useStyles), wilt u deze code misschien ook naar een ander bestand verplaatsen.
Je zou het naar hetzelfde bestand als de hook kunnen verplaatsen. Ik geef er echter de voorkeur aan om het boven de component in hetzelfde bestand te houden of het naar een eigen bestand te verplaatsen als het te groot wordt.
Conclusie
Of je nu denkt dat het gebruik van aangepaste hooks je code verbetert of niet, het komt uiteindelijk neer op persoonlijke voorkeur. Als uw codebase niet veel logica bevat, zijn de voordelen van dit patroon niet zo relevant voor u.
Aangepaste haken zijn slechts één manier om de modulariteit te vergroten; Ik zou het ook ten zeerste aanbevelen componenten en functies opsplitsen in kleinere, herbruikbare brokken wanneer mogelijk.
Het onderwerp wordt ook op een meer algemeen niveau besproken in De pragmatische programmeur. Ik heb een artikel geschreven over mijn favoriete onderwerpen van het boek, dus als dat je interesseert, zorg dan dat je moet je dat zien.
