Die volledige gids vir komponente van hoër orde in React

Blog

Die volledige gids vir komponente van hoër orde in React

Komponente van hoër orde

'N Hoër orde komponent (HOC) is 'n gevorderde tegniek in React vir die hergebruik van komponentlogika. HOC's is op sigself nie deel van die React API nie. Dit is 'n patroon wat uit die samestellende aard van React spruit.



Konkreet, 'n hoër orde komponent is 'n funksie wat 'n komponent neem en 'n nuwe komponent terugstuur.

const EnhancedComponent = higherOrderComponent(WrappedComponent);

Terwyl 'n komponent rekwisiete in UI omskep, verander 'n komponent van 'n hoër orde 'n komponent in 'n ander komponent.



HOC's is algemeen in React-biblioteke van derde partye, soos Redux's connect en Relay's createFragmentContainer .

In hierdie dokument bespreek ons ​​waarom komponente van 'n hoër orde nuttig is en hoe u u eie kan skryf.



Gebruik HOC's vir dwarsbrekende kommer

Let op : Ons het voorheen mengsels aanbeveel as 'n manier om dwarsbrekende probleme te hanteer. Ons het sedertdien besef dat mixins meer probleme veroorsaak as wat dit werd is.

Komponente is die primêre eenheid vir hergebruik van kode in React. U sal egter agterkom dat sommige patrone nie maklik pas by tradisionele komponente nie.

Sê byvoorbeeld dat u 'n | _+_ | komponent wat inteken op 'n eksterne databron om 'n lys kommentaar te lewer:

CommentList

Later skryf u 'n komponent om in te teken op 'n enkele blogpos, wat 'n soortgelyke patroon volg:

class CommentList extends React.Component { constructor(props) { super(props); this.handleChange = this.handleChange.bind(this); this.state = { // 'DataSource' is some global data source comments: DataSource.getComments() }; } componentDidMount() { // Subscribe to changes DataSource.addChangeListener(this.handleChange); } componentWillUnmount() { // Clean up listener DataSource.removeChangeListener(this.handleChange); } handleChange() { // Update component state whenever the data source changes this.setState({ comments: DataSource.getComments() }); } render() { return ( {this.state.comments.map((comment) => ( ))} ); } }

| _+_ | en | _+_ | is nie identies nie - hulle noem verskillende metodes op | _+_ |, en hulle lewer verskillende uitvoer. Maar baie van die implementering daarvan is dieselfde:

  • Voeg op die berg 'n veranderingsluisteraar by | _+_ |.
  • Binne die luisteraar bel | _+_ | wanneer die databron verander.
  • Verwyder die veranderingsluister by ontkoppeling.

U kan u voorstel dat dieselfde patroon in 'n groot app om in te teken op | _+_ | en bel | _+_ | sal oor en oor gebeur. Ons wil 'n abstraksie hê waarmee ons hierdie logika op 'n enkele plek kan definieer en oor baie komponente kan deel. Dit is hier waar komponente van hoër orde uitblink.

Ons kan 'n funksie skryf wat komponente skep, soos | _+_ | en | _+_ |, wat inteken op | _+_ |. Die funksie aanvaar as een van sy argumente 'n kindkomponent wat die ingetekende data as 'n rekwisiet ontvang. Kom ons noem die funksie | _+_ |:

class BlogPost extends React.Component { constructor(props) { super(props); this.handleChange = this.handleChange.bind(this); this.state = { blogPost: DataSource.getBlogPost(props.id) }; } componentDidMount() { DataSource.addChangeListener(this.handleChange); } componentWillUnmount() { DataSource.removeChangeListener(this.handleChange); } handleChange() { this.setState({ blogPost: DataSource.getBlogPost(this.props.id) }); } render() { return ; } }

Die eerste parameter is die toegedraaide komponent. Die tweede parameter haal die data waarin ons belangstel op, gegewe 'n | _+_ | en die huidige rekwisiete.

Wanneer | _+_ | en | _+_ | weergegee word, | _+_ | en | _+_ | sal geslaag word a | _+_ | stut met die mees onlangse data wat verkry is van | _+_ |:

CommentList

Let daarop dat 'n HOC die invoerkomponent nie verander nie, en dit gebruik ook nie erfenis om die gedrag daarvan te kopieer nie. Eerder 'n HOC komponeer die oorspronklike komponent deur toedraai dit in 'n houerkomponent. 'N HOC is 'n suiwer funksie met geen newe-effekte nie.

En dit is dit! Die toegedraaide komponent ontvang al die rekwisiete van die houer, tesame met 'n nuwe stut, | _+_ |, wat dit gebruik om sy uitset te lewer. Die HOK is nie bekommerd oor hoe of waarom die data gebruik word nie, en die toegedraaide komponent maak nie saak waar die data vandaan kom nie.

Omdat | _+_ | is 'n normale funksie, kan u soveel of so min argumente byvoeg as wat u wil. U kan byvoorbeeld die naam van die | _+_ | prop instelbaar, om die HOC verder te isoleer van die toegedraaide komponent. Of u kan 'n argument aanvaar wat | _+_ | instel, of een wat die databron konfigureer. Dit is alles moontlik omdat die HOC volle beheer het oor hoe die komponent gedefinieer word.

hoe om akoin te koop

Net soos komponente, die kontrak tussen | _+_ | en die toegedraaide komponent is volledig op rekwisiete gebaseer. Dit maak dit maklik om een ​​HOC vir 'n ander een te ruil, solank hulle dieselfde rekwisiete aan die toegedraaide komponent bied. Dit kan handig wees as u byvoorbeeld data-ophaalbiblioteke verander.

Moenie die oorspronklike komponent demp nie. Gebruik Samestelling.

Weerstaan ​​die versoeking om die prototipe van 'n komponent in 'n HOC te verander (of andersins te muteer).

BlogPost

Daar is 'n paar probleme hiermee. Die een is dat die invoerkomponent nie apart van die verbeterde komponent hergebruik kan word nie. Belangriker nog, as u 'n ander HOC toepas op | _+_ | daardie ook mutate | _+_ |, word die eerste HOC se funksionaliteit oorskry! Hierdie HOC werk ook nie met funksiekomponente wat nie lewensiklusmetodes het nie.

Muterende HOC's is 'n lekkende abstraksie - die verbruiker moet weet hoe dit geïmplementeer word om konflik met ander HOC's te voorkom.

In plaas van mutasie, moet HOC's samestelling gebruik deur die insetkomponent in 'n houerkomponent te draai:

DataSource

Hierdie HOC het dieselfde funksionaliteit as die muterende weergawe, terwyl die moontlikheid van botsings vermy word. Dit werk ewe goed met klas- en funksiekomponente. En omdat dit 'n suiwer funksie is, kan dit saamgestel word met ander HOC's, of selfs met homself.

U het moontlik ooreenkomste tussen HOC's en 'n patroon genaamd opgemerk houer komponente . Houerkomponente is deel van 'n strategie om verantwoordelikheid te skei tussen hoë- en lae-vlak kommer. Houers bestuur dinge soos intekeninge en state, en gee rekwisiete deur na komponente wat dinge hanteer soos die weergawe van UI. HOC's gebruik houers as deel van die implementering daarvan. U kan HOC's as gedefinieerde definisies van houerkomponente beskou.

Konvensie: Laat onverwante rekwisiete deur na die toegedraaide komponent

HOC's voeg funksies by 'n komponent. Hulle moet nie sy kontrak drasties verander nie. Daar word verwag dat die komponent wat teruggestuur word van 'n HOC 'n soortgelyke koppelvlak het as die toegedraaide komponent.

HOC's moet deur rekwisiete gaan wat nie verband hou met die spesifieke besorgdheid daarvan nie. Die meeste HOC's bevat 'n weergawemetode wat so lyk:

DataSource

Hierdie konvensie help om te verseker dat HOC's so buigsaam en herbruikbaar as moontlik is.

Konvensie: Maksimaliseer die samestelling

Nie alle HOC's lyk dieselfde nie. Soms aanvaar hulle slegs 'n enkele argument, die toegedraaide komponent:

setState

Gewoonlik aanvaar HOC's addisionele argumente. In hierdie voorbeeld van Relay word 'n config -voorwerp gebruik om 'n komponent se data -afhanklikhede te spesifiseer:

DataSource

Die mees algemene handtekening vir HOC's lyk so:

setState

Wat?! As u dit uitmekaar breek, is dit makliker om te sien wat aangaan.

CommentList

Met ander woorde, | _+_ | is 'n hoër orde funksie wat 'n hoër orde komponent teruggee!

Hierdie vorm kan verwarrend of onnodig lyk, maar dit het 'n nuttige eienskap. Enkel-argument HOC's soos die wat deur die | _+_ | teruggestuur word funksie het die handtekening | _+_ |. Funksies waarvan die uitvoertipe dieselfde is as die invoertipe, is baie maklik om saam te stel.

BlogPost

(Dieselfde eiendom laat ook | _+_ | en ander verbeteringsstyl-HOC's toe as versierders, 'n eksperimentele JavaScript-voorstel.)

Die | _+_ | nutfunksie word verskaf deur baie derdeparty-biblioteke, insluitend lodash (as DataSource ), Redux , en Ramda .

Konvensie: draai die vertoningsnaam in vir maklike ontfouting

Die houerkomponente wat deur HOC's geskep is, verskyn in die Reageer ontwikkelaarhulpmiddels soos enige ander komponent. Om ontfouting makliker te maak, kies 'n vertoonnaam wat meedeel dat dit die gevolg is van 'n HOC.

Die mees algemene tegniek is om die vertoonnaam van die toegedraaide komponent toe te draai. As u onderdeel van die hoër orde die naam het | _+_ |, en die omhulde komponent se vertoningnaam is | _+_ |, gebruik die vertoonnaam | _+_ |:

withSubscription

Waarskuwings

Onderdele van hoër orde het 'n paar voorbehoude wat nie onmiddellik duidelik is as u nuut is in React nie.

Moenie HOC's binne die weergawemetode gebruik nie

React se verspreidingsalgoritme (versoening genoem) gebruik komponentidentiteit om te bepaal of dit die bestaande subboom moet opdateer of weggooi en 'n nuwe een moet monteer. As die komponent teruggekeer het van | _+_ | is (| _+_ |) identies aan die komponent van die vorige weergawe, werk React die subboom rekursief op deur dit met die nuwe een te verander. As hulle nie gelyk is nie, word die vorige subboom heeltemal verwyder.

Normaalweg hoef u nie hieroor te dink nie. Maar dit is belangrik vir HOC's, want dit beteken dat u nie 'n HOC op 'n komponent kan toepas binne die weergawemetode van 'n komponent nie:

const CommentListWithSubscription = withSubscription( CommentList, (DataSource) => DataSource.getComments() ); const BlogPostWithSubscription = withSubscription( BlogPost, (DataSource, props) => DataSource.getBlogPost(props.id) );

Die probleem gaan hier nie net oor prestasie nie - die hermontering van 'n komponent veroorsaak dat die toestand van die komponent en al sy kinders verlore gaan.

Pas in plaas daarvan HOC's buite die komponentdefinisie toe, sodat die resulterende komponent slegs een keer geskep word. Die identiteit daarvan sal dan konsekwent wees tussen weergawes. Dit is in elk geval gewoonlik wat u wil hê.

In die seldsame gevalle waar u 'n HOC dinamies moet toepas, kan u dit ook doen binne 'n komponent se lewensiklusmetodes of die konstruktor daarvan.

Statiese metodes moet oorgedra word

Soms is dit nuttig om 'n statiese metode op 'n React -komponent te definieer. Relay -houers stel byvoorbeeld 'n statiese metode | _+_ | bloot om die samestelling van GraphQL -fragmente te vergemaklik.

As u 'n HOC op 'n komponent toepas, is die oorspronklike komponent egter toegedraai met 'n houerkomponent. Dit beteken dat die nuwe komponent nie een van die statiese metodes van die oorspronklike komponent het nie.

DataSource

Om dit op te los, kan u die metodes op die houer kopieer voordat u dit terugstuur:

CommentListWithSubscription

Dit vereis egter dat u presies weet watter metodes gekopieer moet word. Jy kan gebruik hys-nie-reageer-statika om alle nie-reaktiese statiese metodes outomaties te kopieer:

BlogPostWithSubscription

'N Ander moontlike oplossing is om die statiese metode apart van die komponent self uit te voer.

CommentList

Verwysings word nie deurgegee nie

Alhoewel die konvensie vir komponente van 'n hoër orde deur alle rekwisiete na die toegedraaide komponent moet gaan, werk dit nie vir refs nie. Dit is omdat | _+_ | is nie regtig 'n rekwisiet nie - soos | _+_ |, word dit spesiaal deur React hanteer. As u 'n ref byvoeg by 'n element waarvan die komponent die resultaat is van 'n HOC, verwys die ref na 'n instansie van die buitenste houerkomponent, nie die toegedraaide komponent nie.

Die oplossing vir hierdie probleem is om die | _+_ | API (bekendgestel met React 16.3).


Wat is komponente van hoër orde in React?

As u 'n rukkie in die React -ekosisteem was, is daar 'n moontlikheid dat u van komponente van die hoër orde gehoor het. Kom ons kyk na 'n eenvoudige implementering terwyl ons ook probeer om die kernidee te verduidelik. Hiervandaan moet u 'n goeie idee kry van hoe dit werk en dit selfs in gebruik neem.

Waarom komponente van hoër orde?

As u React -toepassings bou, sal u in situasies beland waar u wil deel dieselfde funksionaliteit oor verskeie komponente .

Byvoorbeeld: u moet die toestand van gebruikers wat tans aangemeld is in u toepassing bestuur. In plaas daarvan om die toestand te bestuur oor al die komponente wat die toestand benodig, kan u 'n komponent van hoër orde skep om die aangemelde gebruikersstatus in 'n houerkomponent te skei en die toestand dan deur te gee aan die komponente wat daarvan gebruik sal maak.

Die komponente wat toestand ontvang van die komponent van die hoër orde, sal funksioneer as aanbiedings komponente. Die staat word aan hulle deurgegee en hulle lewer voorwaardelik UI op grond daarvan. Hulle steur hulle nie aan die bestuur van die staat nie.

Kom ons kyk na 'n ander voorbeeld. Gestel u het drie JSON -lêers in u toepassing. Hierdie lêers bevat verskillende data wat in u toepassing in drie verskillende komponente gelaai sal word. U wil u gebruikers die geleentheid gee Soek die data wat uit hierdie lêers gelaai is. U kan 'n soekfunksie in al drie die komponente implementeer. Hierdie duplisering is aanvanklik nie 'n probleem nie, maar namate u toepassing toeneem en meer komponente hierdie funksie benodig, is die konstante duplisering omslagtig en vatbaar vir probleme.

ruil en verkoop

'N Beter pad vorentoe is om 'n komponent van hoër orde te skep om die soekfunksies te hanteer. Hiermee kan u die ander komponente afsonderlik in u komponent van hoër orde toedraai.

Hoe werk komponente van hoër orde?

Die gebruik van komponente van hoër orde is handig as u argitektonies gereed is om houerkomponente van aanbiedingsonderdele te skei. Die aanbiedingskomponent is dikwels 'n staatlose funksionele komponent wat rekwisiete neem en UI lewer. 'N Staatlose funksionele komponente is gewone JavaScript -funksies wat nie state het nie. Hier is 'n voorbeeld:

BlogPost

Die houerkomponent doen die taak om die staat te bestuur. Die houer is in hierdie geval die komponent van die hoër orde.

In die soekvoorbeeld waaroor ons vroeër gepraat het, sou die soekkomponent die houerkomponent wees wat die soektoestand bestuur en die aanbiedingsonderdele wat die soekfunksie benodig, omhul. Die aanbiedingsonderdele het andersins geen idee van die toestand of hoe dit bestuur word nie.

'N Voorbeeld van 'n komponent van hoër orde

Kom ons begin met 'n basiese voorbeeld. Hier is 'n hoër-orde komponent wat gebruikersname in hoofletters transformeer en teruggee:

data

Hierdie komponent van hoër orde ontvang 'n | _+_ | as 'n argument. Dan keer dit terug nuut komponent met rekwisiete daaraan oorgedra om 'n React -element te skep. Ons bel | _+_ | op die | _+_ |, om die geslaagde | _+_ | hoofletters.

Om van hierdie komponent van die hoër orde gebruik te maak, moet ons 'n komponent skep wat rekwisiete ontvang en die kinders weergee.

DataSource

Vervolgens draai ons | _+_ | met die komponent van die hoër orde. Laat ons dit in 'n veranderlike stoor:

// This function takes a component... function withSubscription(WrappedComponent, selectData) { // ...and returns another component... return class extends React.Component { constructor(props) { super(props); this.handleChange = this.handleChange.bind(this); this.state = { data: selectData(DataSource, props) }; } componentDidMount() { // ... that takes care of the subscription... DataSource.addChangeListener(this.handleChange); } componentWillUnmount() { DataSource.removeChangeListener(this.handleChange); } handleChange() { this.setState({ data: selectData(DataSource, this.props) }); } render() { // ... and renders the wrapped component with the fresh data! // Notice that we pass through any additional props return ; } }; }

In ons | _+_ | komponent, kan ons dit nou so gebruik:

data

Die | _+_ | komponent is bloot 'n weergawe van die | _+_ | UI wat op sy beurt weer in staat kom van die | _+_ | tree op as die komponent van die hoër orde.

'N Meer praktiese komponent van hoër orde

Stel jou voor dat ons 'n lys plekke wil skep met 'n soekvorm wat dit filter. Die JSON sal in plat lêers wees en as aparte komponente gelaai word. Kom ons begin deur die data te laai.

Ons eerste komponent laai plekke vir ons gebruikers. Ons sal gebruik maak van | _+_ | om deur die data in die JSON -lêer te blaai.

withSubscription

Hierdie komponent lewer die data in 'n | _+_ | komponent. Ek het dit na 'n ander komponent verskuif om dinge duidelik te hou. Hierdie komponent is 'n funksionele komponent wat die aanbieding van ons data hanteer. Die data (ligging) van die lêer word ontvang via | _+_ |, en elke ligging sal na die | _+_ | komponent.

Nou benodig ons 'n tweede komponent wat uiteindelik ook soekfunksies benodig. Dit sal baie ooreenstem met die eerste komponent wat ons pas gebou het, maar dit sal 'n ander naam hê en data vanaf 'n ander plek laai.

Ons wil hê dat ons gebruikers na items kan soek met 'n | _+_ | veld. Die lys items wat op die app vertoon word, moet bepaal word deur die toestand van die soektog. Hierdie funksie word gedeel oor die twee komponente waaraan ons werk. Danksy die idee van komponente van 'n hoër orde, kan ons 'n soekhouer -komponent skep en dit om ander komponente draai.

Kom ons noem die komponent | _+_ |. Hierdie komponent sal die | _+_ | veld vir ons soektog en bestuur ook ons ​​| _+_ | staat. Die | _+_ | sal as rekwisiete na die toegedraaide komponent deurgegee word, wat gebruik sal word om die getrekte data te filter:

data

Die | _+_ | word 'n toestand van 'n leë string gegee. Die waarde wat die gebruiker in die soekkassie ingevoer het, word verkry en gebruik om die nuwe toestand in te stel vir | _+_ |. Vervolgens slaag ons | _+_ | na die | _+_ |. Ons sal hiervan gebruik maak wanneer die data gefiltreer word.

Om gebruik te maak van die komponent van die hoër orde, moet ons 'n paar veranderinge aan ons aanbiedingskomponent aanbring.

shouldComponentUpdate

Die eerste ding wat ons hierbo gedoen het, is om die komponent van die hoër orde in te voer. Dan voeg ons 'n filtermetode by om die data te filter op grond van wat die gebruiker in die soekinvoer invoer. Laastens moet ons dit met die | _+_ | komponent.

Afsluiting

Komponente van hoër orde hoef nie eng te wees nie. Nadat u die basiese beginsels verstaan ​​het, kan u die konsep gebruik deur funksionaliteite wat onder verskillende komponente gedeel kan word, te onttrek.


Inleiding tot hoër orde komponente (HOC) in React

Hierdie artikel is bedoel om u 'n idee te gee van hoe komponente van 'n hoër orde werk, en wanneer en waarom u dit moet gebruik. Ons sal dit beginnersvriendelik hou om u te help om die konsep beter te verstaan ​​en waarom dit bestaan.

elgato -afstandsbediening -inprop ontbreek

Onderdele van hoër orde is in die algemeen 'n funksionele programmeermetode. Hierdie artikel benodig egter geen funksionele programmeringskennis nie, maar benodig basiese kennis in React.

Ons bespreek 'n paar funksionele programmeringskonsepte wat u sal help om HOC beter te reageer.

Kom ons begin met die formele definisie:

'N Hoër orde komponent is 'n funksie wat 'n komponent neem en 'n nuwe komponent terugstuur.

HOC is nie 'n kenmerk in React of enige ander programmeertaal nie, maar 'n patroon het ontstaan ​​uit die kompositoriese (gemaak van komponente) aard van reageer.

Funksionele programmering en funksies van hoër orde

'N Hoër orde funksie is 'n funksie wat 'n ander funksie as 'n argument aanvaar. U sou die kaart funksie wat onder hierdie kategorie val.

Dit is 'n konsep wat ontleen is aan die wêreld van funksionele programmering. Maar waarom 'n funksionele programmeringskonsep in React gebruik?

Die doel van hierdie patroon is om die logika te ontbind in eenvoudiger en kleiner funksies wat hergebruik kan word. 'N Duimreël is dat 'n funksie net een taak verrig en dit goed doen. Dit vermy ook newe -effekte (verander enigiets wat nie die funksie besit nie), en maak ontfouting en onderhoud baie makliker.

'N Klassieke voorbeeld van funksionele programmeringsvoorbeeld is die vermenigvuldiging:

withSubscription

Net so neem 'n HOC 'n ander komponent as argument.

Kom ons bou 'n HOC en leer meer namate ons gaan.

Komponent van hoër orde in React

Kom ons kyk dadelik na die een of ander kode.

function logProps(InputComponent) { InputComponent.prototype.componentDidUpdate = function(prevProps) { console.log('Current props: ', this.props); console.log('Previous props: ', prevProps); }; // The fact that we're returning the original input is a hint that it has // been mutated. return InputComponent; } // EnhancedComponent will log whenever props are received const EnhancedComponent = logProps(InputComponent);

Bogenoemde voorbeeld neem 'n komponent en keer die inhoud daarin om. | _+_ | is 'n HOC, wat 'n element inneem (| _+_ | in die voorbeeld), die inhoud in daardie element vind, dit omkeer en 'n element met omgekeerde inhoud uitspoeg.

Wat hierbo getoon word, is 'n uiters eenvoudige gebruiksvoorwaarde om die konsep te verstaan.

Twee dinge gebeur met 'n HOC

  1. Neem 'n komponent as argument
  2. Gee iets terug

Kom ons kyk na 'n meer praktiese en komplekse gebruiksgeval.

In al die programme wat ons in die verlede geskep het, is daar 'n vertraging as ons data vanaf 'n API moet laai.

Gewoonlik is daar 'n tydsverloop tussen die weergawe van die bladsy en die werklike data. Die meeste programme wys 'n laai -animasie om die gebruikerservaring beter te maak. Laat ons 'n laai -animasie -komponent bou om die konsep van HOC te demonstreer.

Ons sal na sekere dele van die repo verwys namate ons vorder. Dit is 'n reageer -app gemaak met | _+_ | .

Laat ons eers verstaan ​​hoe die app werk. Ons gebruik randomuser.me om enkele steekproefdata te genereer. Kom ons neem aan dat ons 'n voer van ewekansige gebruikers bou. In | _+_ | ons rig 'n versoek aan | _+_ | om 'n paar ewekansige data te kry. Die versoek sal binne die | _+_ | funksie.

EnhancedComponent

Die ewekansige data van die API word verwerk, aangesien ons slegs geïnteresseerd is in die naam, e -posadres en die prentjie, ons filtreer dit en stel dit in die app -toestand. Sodra ons die data het, slaag ons die | _+_ | aan ons | _+_ | voorwerp as

componentDidUpdate

Hier is hoe ons voer -komponent lyk. Dit stuur eenvoudig die ontvangde kontakdata na | _+_ |. En FeedItem herhaal deur die data om dit werklik te vertoon.

function logProps(WrappedComponent) { return class extends React.Component { componentDidUpdate(prevProps) { console.log('Current props: ', this.props); console.log('Previous props: ', prevProps); } render() { // Wraps the input component in a container, without mutating it. Good! return ; } } }

U sou opgemerk het dat die uitvoerverklaring verskil van die normale geval. In plaas van | _+_ | ons voer die | _+_ | komponent toegedraai in 'n | _+_ | Dit is omdat ons laai -HOC 'n funksie is. Kerrie is die proses om 'n funksie af te breek in 'n reeks funksies wat elkeen a enkele argument .

Kom ons kyk na ons laai -komponent.

render() { // Filter out extra props that are specific to this HOC and shouldn't be // passed through const { extraProp, ...passThroughProps } = this.props; // Inject props into the wrapped component. These are usually state values or // instance methods. const injectedProp = someStateOrInstanceMethod; // Pass props to wrapped component return ( ); }

Kom ons verstaan ​​hoe die komponent stap vir stap werk.

  1. Om dit makliker te verstaan, neem komponent 'n ander komponent (in ons geval | _+_ | komponent) saam met 'n eiendom | _+_ |
  2. Nou die | _+_ | komponentkontroles van die | _+_ | (in ons geval | _+_ |) is leeg - Die funksie | _+_ | doen dit.
  3. As dit leeg is, is die | _+_ | komponentopbrengs
const NavbarWithRouter = withRouter(Navbar);

Ons gebruik die klasnaam | _+_ | om 'n paar style by te voeg en die laaier te implementeer.

  1. Andersins gee u die oorspronklike komponent terug met opsionele byvoegingseienskappe (in hierdie geval | _+_ |

  2. In ons voorbeeld het ons die laaityd vir die demonstrasiedoeleindes bereken en om aan te toon dat ons data kan terugstuur. Wat u met dieselfde kan doen, word aan u verbeelding oorgelaat.

So, wat gebeur as ons enige komponent in die laai -komponente saam met 'n eiendomsnaam toedraai?

Dit kontroleer of die geslaagde eiendomsnaam leeg is.

As die laaikomponent leeg is, word die oorspronklike komponent teruggestuur as daar data is.

Dit sluit die implementering van ons HOC af.

Noudat ons verstaan ​​het hoe om 'n HOC te skryf, kan ons die wanneer en waarom verstaan.

In 'n normale geval, om 'n laaikomponent te implementeer, kan ons kyk of die ooreenstemmende eienskap (| _+_ | in ons voorbeeld) in die onderskeie komponent is en 'n | _+_ | komponent binne die oorspronklike komponent.

Dit sal egter lei tot oortollige kode. Ons het byvoorbeeld 'n | _+_ | komponent beheer deur | _+_ | en 'n | _+_ | komponent wat deur | _+_ | beheer word, moet ons kyk of die data in twee verskillende gevalle voorkom en die laaikomponente weergee.

'N Generiese komponent van die hoër orde, soos in die voorbeeld hierbo getoon, vermy dit. In die geval moet ons laai vir die | _+_ | komponent, in die | _+_ | ons kan eenvoudig doen

const CommentWithRelay = Relay.createContainer(Comment, config);

Dit is slegs een toepassing van HOC, u kan dit op enige manier gebruik. Eintlik is dit wat dit doen

  1. Neem 'n komponent as argument
  2. Gee iets terug - dit kan alles wees. Letterlik enigiets. U kan die oorspronklike komponent heeltemal verontagsaam en iets heeltemal nuuts weergee.

Wat u wil doen, hang af van u verbeelding. Kortom, HOC help u om u kodebasis op 'n baie beter manier te organiseer en om kode -oortolligheid te verminder.

Selfs Redux gebruik HOC. Die connect -verklaring wat u teëgekom het, is 'n HOC wat soveel dinge doen met die oorspronklike komponent.

As u sien dat dieselfde kode op baie plekke in u kodebasis geskryf is, is daar 'n kans om dit na 'n HOC te skuif en u kodebasis baie skoner te maak.


Reageer komponente vir hoër bestellings vir die nuweling

U het dus nou in React gekodeer en daarvan gehou! Fantasties! Het u geweet van hierdie interessante patroon wat u in React, High Order Components, kan gebruik? Kom ons kyk in hierdie berig vinnig na wat hoër komponente is en hoe u dit in u app kan gebruik?

Ja, ek weet dat u soos hierdie kind is, nog 'n nuwe ding om te leer?!?! Ja, vertrou my, dit is nie moeilik nie, en dit kan handig wees as jy jou React -program kodeer! En dit is heeltemal opsioneel; u kan steeds ongelooflike React -programme bou sonder komponente van hoër orde. Maar dit is 'n algemene ontwerppatroon wat u sal waardeer en gebruik sodra u leer wat dit is.

Agtergrond: hoë orde funksies

Die konsep van 'n hoë -orde -komponent is nie 'n nuwe idee wat saam met React gekom het nie. In JavaScript gebruik ons ​​soms 'n hoë orde funksie.

'N Funksie wat 'n ander funksie aanvaar en/of teruggee, word 'n hoër-orde funksie genoem.

Die diagram hieronder stel 'n hoë orde funksie konseptueel voor.

hoër orde funksie

Ek het 'n rukkie gelede 'n artikel hieroor geskryf, wat u kan lees om 'n beter begrip van funksies van hoë orde te kry.

Wat is hoë orde funksies in JavaScript?

Wat is React Higher Order Components

Nou kan ons dieselfde konsep uitbrei na die komponentargitektuur in React. In React is alles 'n komponent.

'N Hoër orde komponent (HOC) is 'n funksie wat 'n komponent neem en 'n komponent terugstuur.

** Opmerking: ** HOC's maak nie regtig deel uit van die React API nie, maar dit is eerder 'n kodepatroon wat goed pas by React vanweë die samestellende aard daarvan.

Die probleem HOC's los op

Voordat ons begin met die skryf van komponente van hoër orde, is dit billik om te vra: Wat is die probleem wat HOC's probeer oplos?

In sagteware -ontwikkeling is een van die algemene beginsels waaroor daar gereeld gepraat word Moenie jouself herhaal nie aka. DROOG. Ek het gedurende my loopbaan die DRY -beginsel in verskeie tale gebruik, en ek is aangeraai om dit deur kundiges in die bedryf te doen. U het moontlik gereeld 'n eenvoudige nutsfunksie geskep wat in verskillende dele van die kodebasis gebruik word. U volg in wese DRY deur dit te doen. U hergebruik dieselfde nutsfunksie sonder om die kode te herhaal.

In React, is een van die maniere om DRY tussen komponente te bereik, die konsep van die Higher Order Component (HOC). U kan algemene funksies deel sonder om kode te herhaal met HOC's.

Struktuur van HOC

Hier is hoe 'n HOC in React lyk. Die komponent van die hoër orde is in wese 'n funksie wat 'n komponent as 'n argument inneem en 'n nuwe komponent terugstuur. Dit kan ook die oorspronklike komponent wat daaraan oorgedra is, weergee as 'n argument.

// React Redux's `connect` const ConnectedComment = connect(commentSelector, commentActions)(CommentList);

In die eenvoudige voorbeeld sien ons bo die _myHOC _is 'n funksie wat inneem myOtherComponent as parameter. Dit gee dan 'n nuwe komponent terug. Die nuwe komponent bevat _myOtherComponent _ as 'n kind in hierdie geval.

Ek leer deur voorbeeld!

Op hierdie stadium kan u 'n idee kry van watter komponente van hoër orde in React is en waarom dit gebruik word. Om op te som:

  • HOC -funksie wat 'n komponent inneem en 'n nuwe komponent terugstuur.
  • Dit word hoofsaaklik gebruik om kode te hergebruik en die DRY -beginsel in React te volg.
  • Dit is nie 'n API nie en is 'n ontwerppatroon wat goed in React pas.

Goed, kom ons kyk na 'n eenvoudige voorbeeld om te verstaan ​​hoe HOC's in werking gestel kan word.

Skep komponent

// connect is a function that returns another function const enhance = connect(commentListSelector, commentListActions); // The returned function is a HOC, which returns a component that is connected // to the Redux store const ConnectedComment = enhance(CommentList);

Ek het 'n komponent geskep Bloginligting en hierdie komponent is 'n eenvoudige klaskomponent wat die naam van die outeur vertoon, en die naam van die artikel wat deur 'n outeur geskryf is. Beide die naam en die artikel word as _props aan die komponent oorgedra. _ Eenvoudig genoeg!

Bel komponent

Ek gaan hierdie komponent uit die App.js lêer en gee die _props _ daaraan.

connect

Tot dusver het ons niks spesiaals gedoen nie. Ons het pas 'n komponent geskep en die komponent genoem uit die ouerkomponent. As ons hierdie kode gebruik, sal ons dit sien.

Goed, laat ons nou begin dink oor die verbetering van hierdie komponent. Wat as ek wil hê dat die naam van die outeur en Geen artikels in die artikelafdeling moet verskyn nie, as geen artikel as rekwisiet aangeneem word nie? As daar geen outeur aan die komponent oorgedra is nie, wil ek hê dat dit ook 'n persoonlike boodskap moet vertoon. Op hierdie punt begin die komponent groei. Hou in gedagte dat ons nog steeds te doen het met 'n eenvoudige funksie dat ons dit alles in een komponent kan hê, sonder die gebruik van 'n HOC. Maar hierdie post wil die gebruik van HOC illustreer met 'n eenvoudige voorbeeld om te verstaan ​​hoe u dit moet gebruik.

Goed, ek gaan ons _BlogInformation _ -komponent 'n bietjie aanpas.

connect

Ons gaan Geen artikels vertoon as die artikel is nie geslaag in die rekwisiete.

Skep 'n hoër orde komponent

Dit is 'n goeie kans om 'n HOC vir die res van die veranderinge te skep.

Component => Component

Hier is 'n opsomming van die kode hierbo:

hoe om mobilecoin te koop
  • Ons het 'n HOC _myHOCFunction geskep, _wat 'n komponent inneem en 'n nuwe komponent terugstuur.
  • Hierdie funksie kyk of die skrywer is in die _ rekwisiete _ aan die komponent deurgegee.
  • As die 'outeur' bestaan, word die komponent wat geslaag is sonder weergawes weergegee.
  • As die inligting van die outeur nie beskikbaar is nie, gee dit 'n nuwe komponent met 'n persoonlike boodskap weer.
  • Teen die einde doen ons 'n beroep op die HOC deur die komponent _BlogInformation _ as parameter in te gee.

Elke keer as die komponent _BlogInformation _ genoem word, gaan dit na die HOC myHOCFunction en lewer in plaas daarvan. U kan nou die idee kry waarom HOC vir u nuttig kan wees in groot React -projekte. U kan moontlik HOC's skep om 'n ton kode te hergebruik, wat andersins herhalend sou gewees het.

Om te sien hoe dit werk, kan u na die onderstaande kode sandbox gaan:

Afsluiting

Met komponente van hoër orde kan u u kode abstrakteer, en as u dit eers onder die knie kry, gebruik u moontlik hierdie patroon te gereeld. Weereens, HOC is slegs 'n ontwerppatroon, en u kan kies of u dit wil gebruik, afhangende van u koderingstyl en voorkeure.

#reactjs #webontwikkeling #javascript