Jos olet työskennellyt Reactin kanssa jonkin aikaa, olet todennäköisesti törmännyt siihen astia ja esittelykomponentit , tai älykkäitä ja tyhmiä komponentteja. Nämä termit kuvaavat a kuvio joka erottaa React-komponenttien käyttöliittymäkerroksen logiikasta.
Käyttöliittymän erottaminen liiketoimintalogiikasta ei ole mitään ainutlaatuista Reactille: huolenaiheiden erottaminen on suunnitteluperiaate, joka ollut jo 70-luvulla. Esimerkiksi on yleinen käytäntö erottaa tietokantaa käyttävä koodi taustajärjestelmän liiketoimintalogiikasta.
Joten Reactissa ratkaisimme tämän ongelman luomalla säiliökomponentteja, jotka sisältävät kaiken logiikan, jotka sitten välittäisivät tiedot rekvisiittajen kautta esityskomponenttiin.
React-koukkujen käyttöönoton myötä tähän on uusi lähestymistapa: käyttö mukautetut koukut.
Miksi meidän pitäisi erottaa logiikka komponentista?
Ennen kuin aloitamme logiikan irrottamisen React-komponenteistamme, meidän pitäisi tietää miksi.
Järjestämällä koodimme tavalla, jossa jokainen toiminto tai komponentti vastaa vain yhdestä asiasta, on se etu, että se on paljon helpompi muuttaa ja ylläpitää (Dave ja Andrew kutsuvat tätä "ortogonaalisuus" kirjassaan Pragmaattinen ohjelmoija).
Tämän käyttäminen Reactissa tarkoittaa, että komponenttimme näyttää puhtaammalta ja järjestäytyneemmältä. Meidän ei tarvitse vierittää logiikkamuurin ohi esimerkiksi ennen käyttöliittymän muokkaamista.
Koodin järjestäminen tällä tavalla ei ainoastaan tee siitä paremman ulkonäön ja helpompaa navigointia, vaan myös helpottaa vaihtamista, koska koukun vaihtaminen ei vaikuta käyttöliittymään ja päinvastoin.
Testaus on myös helpompaa: voimme testata logiikkaa erillään käyttöliittymästä, jos haluamme. Suurin etu minulle on kuitenkin se, miten tämä lähestymistapa järjestää koodini.
Kuinka irrottaa logiikka React-koukkujen avulla
Logiikan erottamiseksi komponentistamme luomme ensin mukautetun koukun.
Otetaan tämä komponentti esimerkkinä. Se laskee kantaluvun ja eksponentin eksponenttiarvon:
Löydät täydellisen lähdekoodin tätä.
Koodi näyttää tältä:
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>
);
};
Tämä saattaa jo näyttää hyvältä, mutta tämän opetusohjelman vuoksi vain kuvitella että tässä on enemmän logiikkaa.
Ensimmäisenä askeleena teemme siirrä logiikka mukautettuun koukkuun ja kutsua sitä komponenttimme sisällä.
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();
// ...
};
Voisimme siirtää tämän koukun a erillinen tiedosto huolenaiheiden selkeämpään erotteluun.
Lisäksi voimme edelleen jakaa koukkumme pienempiin, uudelleenkäytettäviin toimintoihin. Tässä tapauksessa voimme vain poimia calculateExponent.
useExponentCalculator.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);
// ...
};
Näiden toimintojen testaus on paljon helpompaa kuin koko komponentin koodin testaus ensimmäisestä esimerkistä. Voisimme testata niitä millä tahansa Node.js-testauskirjastolla, jonka ei tarvitse edes tukea React-komponentteja.
Meillä on nyt kehyskohtainen koodimme (React) komponentin ja koukun koodissa, kun taas liiketoimintalogiikkamme elää myöhemmin määrittämissämme eri funktioissa (jotka ovat kehysagnostisia).
Parhaat käytännöt
Nimeäminen
Haluan nimetä mukautetut koukut komponentin mukaan ketjutuksena use ja komponentin nimi (esim useExponentCalculator). soitan sitten tiedosto sama kuin koukku.
Haluat ehkä noudattaa erilaista nimeämiskäytäntöä, mutta suosittelen pysyä johdonmukaisena projektissasi.
Jos voin käyttää uudelleen mukautetun koukun osia, siirrän sen yleensä toiseen tiedostoon src/hooks.
Älä liioittele sitä
Yritä olla pragmaattinen. Jos komponentissa on vain muutama JS-rivi, logiikkaa ei tarvitse erottaa.
CSS-JS: ssä
Jos käytät CSS-in-JS-kirjastoa (useStyles), voit myös siirtää tämän koodin toiseen tiedostoon.
Voit siirtää sen samaan tiedostoon kuin koukku. Pidän kuitenkin mieluummin sen komponentin yläpuolella samassa tiedostossa tai siirrän sen omaan tiedostoonsa, jos se kasvaa liian suureksi.
Yhteenveto
Uskotpa, että mukautettujen koukkujen käyttö parantaa koodiasi vai ei, se riippuu lopulta henkilökohtaisista mieltymyksistä. Jos koodikantasi ei sisällä paljon logiikkaa, tämän mallin edut eivät ole sinulle kovin tärkeitä.
Mukautetut koukut ovat vain yksi tapa lisätä modulaarisuutta; Suosittelen myös lämpimästi komponenttien ja toimintojen jakaminen pienempiin uudelleenkäytettäviin osiin kun mahdollista.
Aiheesta keskustellaan myös yleisemmällä tasolla Pragmaattinen ohjelmoija. Kirjoitin artikkelin, joka kattaa kirjan suosikkiaiheitani, joten jos se kiinnostaa sinua, varmista tarkista se.
