Reagere.Komponent

Denne siden inneholder en detaljert API-referanse for React component class-definisjonen. Det forutsetter at du er kjent med grunnleggende React-konsepter, For Eksempel Komponenter og Rekvisitter, Samt Tilstand og Livssyklus. Hvis ikke, les dem først.

Oversikt

React lar deg definere komponenter som klasser eller funksjoner. Komponenter definert som klasser for tiden gi flere funksjoner som er beskrevet i detalj på denne siden. For å definere En React-komponentklasse må du utvide React.Component:

class Welcome extends React.Component { render() { return <h1>Hello, {this.props.name}</h1>; }}

den eneste metoden du må definere i enReact.Componentunderklasse kallesrender(). Alle de andre metodene som er beskrevet på denne siden er valgfrie.

Vi anbefaler sterkt at du ikke lager dine egne grunnkomponentklasser. I React-komponenter oppnås kodegjenbruk primært gjennom sammensetning i stedet for arv.

Merk:

React tvinger deg ikke til Å bruke ES6-klassesyntaksen. Hvis du foretrekker å unngå det, kan du brukecreate-react-class modulen eller en lignende tilpasset abstraksjon i stedet. Ta en titt På Å Bruke React uten ES6 for å lære mer.

Komponentlivssyklusen

Hver komponent har flere «livssyklusmetoder» som du kan overstyre for å kjøre kode på bestemte tidspunkter i prosessen. Du kan bruke dette livssyklusdiagrammet som et jukseark. I listen nedenfor er vanlige livssyklusmetoder merket som fet. Resten av dem eksisterer for relativt sjeldne brukssaker.

Montering

disse metodene kalles i følgende rekkefølge når en forekomst av en komponent blir opprettet og satt inn I DOM:

• constructor()

static getDerivedStateFromProps()render()

• componentDidMount()

merk:

disse metodene anses som eldre, og du bør unngå dem i ny kode:

• UNSAFE_componentWillMount()

oppdatering

EN OPPDATERING kan skyldes endringer i rekvisitter eller tilstand. Disse metodene kalles i følgende rekkefølge når en komponent blir gjengitt:

• static getDerivedStateFromProps()

shouldComponentUpdate()render()

• getSnapshotBeforeUpdate()

componentDidUpdate()

merk:

disse metodene anses som eldre, og du bør unngå dem i ny kode:

UNSAFE_componentWillUpdate()UNSAFE_componentWillReceiveProps()

Demontering

denne metoden kalles når en komponent blir fjernet fra DOM:

• componentWillUnmount()

feilhåndtering

disse metodene kalles når det oppstår en feil under gjengivelse, i en livssyklusmetode eller i konstruktøren av en hvilken som helst barnekomponent.

static getDerivedStateFromError()componentDidCatch()

Andre Apier

Hver komponent gir også noen Andre Apier:

• setState()

forceUpdate()

Klasseegenskaper

defaultPropsdisplayName

forekomst egenskaper

propsstate

referanse

vanlige livssyklusmetoder

metodene i denne delen dekker de aller fleste av brukstilfeller vil du støte på å skape react-komponenter. For en visuell referanse, sjekk ut dette livssyklusdiagrammet.

render ()

render()

render() metoden er den eneste nødvendige metoden i en klassekomponent.

når den kalles, bør den undersøke this.props og this.state og returnere en av følgende typer:

• React-elementer. Vanligvis opprettet via JSX. For eksempel er<div /> og<MyComponent /> React-elementer som instruerer React til å gjengi EN DOM-node eller en annen brukerdefinert komponent.
• Matriser og fragmenter. La deg returnere flere elementer fra gjengi. Se dokumentasjonen på fragmenter for flere detaljer.
• Portaler. La deg gjøre barn til et annet DOM-subtre. Se dokumentasjonen på portaler for mer informasjon.
• Streng og tall. Disse gjengis som tekstnoder I DOM.
• Booleans eller null. Gjengi ingenting. (For det meste eksisterer for å støttereturn test && <Child /> mønster, dertest er boolsk.)

render() – funksjonen skal være ren, noe som betyr at den ikke endrer komponentstatus, den returnerer det samme resultatet hver gang det blir påkalt, og det samhandler ikke direkte med nettleseren.

hvis du trenger å samhandle med nettleseren, utfør arbeidet ditt i componentDidMount() eller de andre livssyklusmetodene i stedet. Å holde render() pure gjør komponenter enklere å tenke på.

Merk

render() vil ikke bli påberopt hvis shouldComponentUpdate() returnerer usann.

constructor ()

constructor(props)

hvis du ikke initialiserer tilstand og du ikke binder metoder, trenger du ikke å implementere en konstruktør for Din React-komponent.

konstruktøren for En Reaksjonskomponent kalles før den monteres. Når du implementerer konstruktøren for en React.Component underklasse, bør du ringe super(props) før noen annen setning. Ellers vil this.props være udefinert i konstruktøren, noe som kan føre til feil.

Vanligvis Brukes React-konstruktører Bare til to formål:

• Initialiserer lokal tilstand ved å tilordne et objekt tilthis.state.
• Binding hendelsesbehandlingsmetoder til en forekomst.

du bør ikke ringesetState() i constructor(). I stedet, hvis komponenten din trenger å bruke lokal tilstand, tilordne den opprinnelige tilstanden til this.state direkte i konstruktøren:

constructor(props) { super(props); // Don't call this.setState() here! this.state = { counter: 0 }; this.handleClick = this.handleClick.bind(this);}

Konstruktør er det eneste stedet hvor du skal tilordnethis.state direkte. I alle andre metoder må du bruke this.setState() i stedet.

Unngå å innføre bivirkninger eller abonnementer i konstruktøren. For de brukstilfeller, bruk componentDidMount() i stedet.

Merk

Unngå å kopiere rekvisitter til staten! Dette er en vanlig feil:

constructor(props) { super(props); // Don't do this! this.state = { color: props.color };}

problemet er at det er både unødvendig (du kan brukethis.props.color direkte i stedet), og skaper bugs (oppdateringer tilcolor prop vil ikke bli reflektert i staten).

bruk bare dette mønsteret hvis du med vilje vil ignorere prop-oppdateringer. I så fall er det fornuftig å omdøpe prop som skal kalles initialColor eller defaultColor. Du kan deretter tvinge en komponent til å «tilbakestille» sin interne tilstand ved å endre key når det er nødvendig.

Les vårt blogginnlegg om å unngå avledet tilstand for å lære om hva du skal gjøre hvis du tror du trenger noen stat til å stole på rekvisitter.

componentDidMount ()

componentDidMount()

componentDidMount() startes umiddelbart etter at en komponent er montert (satt inn i treet). Initialisering som krever DOM noder bør gå her. Hvis du trenger å laste inn data fra et eksternt endepunkt, er dette et bra sted å starte nettverksforespørselen.

denne metoden er et godt sted å sette opp abonnementer. Hvis du gjør det, ikke glem å melde deg av i componentWillUnmount().

du kan ringe setState() umiddelbart i componentDidMount(). Det vil utløse en ekstra gjengivelse, men det vil skje før nettleseren oppdaterer skjermen. Dette garanterer at selv om render() vil bli kalt to ganger i dette tilfellet, vil brukeren ikke se mellomstatusen. Bruk dette mønsteret med forsiktighet fordi det ofte fører til ytelsesproblemer. I de fleste tilfeller bør du kunne tilordne opprinnelig tilstand iconstructor() i stedet. Det kan imidlertid være nødvendig for tilfeller som modaler og verktøytips når du må måle EN DOM-node før du gjengir noe som avhenger av størrelsen eller posisjonen.

componentDidUpdate ()

componentDidUpdate(prevProps, prevState, snapshot)

componentDidUpdate() startes umiddelbart etter oppdatering. Denne metoden kalles ikke for den første gjengivelsen.

Bruk DETTE som en mulighet til å operere PÅ DOM når komponenten er oppdatert. Dette er også et bra sted å gjøre nettverksforespørsler så lenge du sammenligner gjeldende rekvisitter med tidligere rekvisitter (f. eks. en nettverksforespørsel kan ikke være nødvendig hvis rekvisitter ikke er endret).

componentDidUpdate(prevProps) { // Typical usage (don't forget to compare props): if (this.props.userID !== prevProps.userID) { this.fetchData(this.props.userID); }}

Du kan ringe setState() umiddelbart i componentDidUpdate() men merk at det må pakkes inn i en tilstand som i eksemplet ovenfor, eller du vil forårsake en uendelig sløyfe. Det vil også føre til en ekstra re-rendering som, mens ikke synlig for brukeren, kan påvirke komponentytelsen. Hvis du prøver å «speile» noen stat til en prop som kommer ovenfra, bør du vurdere å bruke prop direkte i stedet. Les mer om hvorfor kopiering rekvisitter til staten forårsaker feil.

hvis komponenten implementerergetSnapshotBeforeUpdate() livssyklus (som er sjelden), vil verdien den returnerer sendes som en tredje «snapshot» parameter tilcomponentDidUpdate(). Ellers vil denne parameteren være udefinert.

Merk

componentDidUpdate() vil ikke bli påberopt hvis shouldComponentUpdate() returnerer usann.

componentWillUnmount ()

componentWillUnmount()

componentWillUnmount() startes umiddelbart før en komponent demonteres og ødelegges. Utfør all nødvendig opprydding i denne metoden, for eksempel ugyldiggjøre timere, avbryte nettverksforespørsler eller rydde opp eventuelle abonnementer som ble opprettet i componentDidMount().

du bør ikke ringe setState() i componentWillUnmount() fordi komponenten aldri vil bli gjengitt på nytt. Når en komponentforekomst er demontert, vil den aldri bli montert igjen.

Metoder For Sjeldent Brukte Livssykluser

metodene i denne delen tilsvarer uvanlige brukstilfeller. De er praktiske en gang i blant, men de fleste komponentene trenger sannsynligvis ikke noen av dem. Du kan se de fleste metodene nedenfor på dette livssyklusdiagrammet hvis du klikker på avkrysningsruten «Vis mindre vanlige livssykluser» øverst i det.

shouldComponentUpdate ()

shouldComponentUpdate(nextProps, nextState)

Bruk shouldComponentUpdate() For Å la React vite om en komponents utgang ikke påvirkes av gjeldende endring i tilstand eller rekvisitter. Standard virkemåte er å re-gjengi på hver tilstand endring, og i de aller fleste tilfeller bør du stole på standard virkemåte.

shouldComponentUpdate() påberopes før gjengivelse når nye rekvisitter eller tilstand mottas. Standardinnstillingene er true. Denne metoden kalles ikke for den første gjengivelsen eller nårforceUpdate() brukes.

denne metoden eksisterer bare som en ytelsesoptimalisering. Ikke stole på det for å «hindre» en gjengivelse, da dette kan føre til feil. Vurder å bruke den innebygde PureComponent i stedet for å skrive shouldComponentUpdate() for hånd. PureComponent utfører en grunne sammenligning av rekvisitter og tilstand, og reduserer sjansen for at du hopper over en nødvendig oppdatering.

hvis du er sikker på at du vil skrive den for hånd, kan du sammenligne this.props med nextProps og this.state med nextState og returnere false for å fortelle react kan oppdateringen hoppes over. Merk at retur false forhindrer ikke at barnekomponenter gjengis på nytt når tilstanden endres.

vi anbefaler ikke å gjøre dype likestillingskontroller eller bruke JSON.stringify() i shouldComponentUpdate(). Det er svært ineffektivt og vil skade ytelsen.

for Øyeblikket, hvis shouldComponentUpdate() returnerer false, så UNSAFE_componentWillUpdate()render() og componentDidUpdate() vil ikke bli påberopt. I fremtiden Kan React behandle shouldComponentUpdate() som et hint i stedet for et strengt direktiv ,og returfalse kan fortsatt resultere i en re-gjengivelse av komponenten.

statisk getDerivedStateFromProps ()

static getDerivedStateFromProps(props, state)

getDerivedStateFromProps påberopes rett før du ringer til gjengivelsesmetoden, både på den første monteringen og på påfølgende oppdateringer. Det bør returnere et objekt for å oppdatere staten, eller null for å oppdatere ingenting.

denne metoden finnes i sjeldne tilfeller der tilstanden avhenger av endringer i rekvisitter over tid. For eksempel kan det være nyttig å implementere en<Transition> komponent som sammenligner sine tidligere og neste barn for å bestemme hvilken av dem som skal animere inn og ut.

Avledet tilstand fører til ordrik kode og gjør komponentene vanskelig å tenke på.Sørg for at du er kjent med enklere alternativer:

• hvis du trenger å utføre en bivirkning (for eksempel datahenting eller en animasjon) som svar på en endring i rekvisitter, bruk componentDidUpdate livssyklus i stedet.
• hvis du ønsker å re-beregne noen data bare når en rekvisitt endringer, bruke en memoization helper stedet.
• hvis du vil «tilbakestille» en tilstand når en prop endres, bør du vurdere å gjøre en komponent fullt kontrollert eller helt ukontrollert med en key i stedet.

denne metoden har ikke tilgang til komponentforekomsten. Hvis du vil, kan du gjenbruke noen kode mellom getDerivedStateFromProps() og de andre klassemetodene ved å trekke ut rene funksjoner av komponentrekvisitter og tilstand utenfor klassedefinisjonen.

Merk at denne metoden er avfyrt på hver gjengivelse, uavhengig av årsaken. Dette er i motsetning til UNSAFE_componentWillReceiveProps, som bare brenner når foreldrene forårsaker en gjengivelse og ikke som følge av en lokal setState.

getSnapshotBeforeUpdate ()

getSnapshotBeforeUpdate(prevProps, prevState)

getSnapshotBeforeUpdate() påberopes rett før den sist gjengitte utgangen er forpliktet til F.EKS. DOM. Det gjør at komponenten din kan fange opp litt informasjon FRA DOM (f.eks. Enhver verdi som returneres av denne livssyklusen, sendes som en parameter til componentDidUpdate().

denne brukssaken er ikke vanlig, men det kan forekomme I UIs som en chat-tråd som må håndtere rulleposisjon på en spesiell måte.

en snapshot-verdi (eller null) skal returneres.

For eksempel:

class ScrollingList extends React.Component { constructor(props) { super(props); this.listRef = React.createRef(); } getSnapshotBeforeUpdate(prevProps, prevState) { // Are we adding new items to the list? // Capture the scroll position so we can adjust scroll later. if (prevProps.list.length < this.props.list.length) { const list = this.listRef.current; return list.scrollHeight - list.scrollTop; } return null; } componentDidUpdate(prevProps, prevState, snapshot) { // If we have a snapshot value, we've just added new items. // Adjust scroll so these new items don't push the old ones out of view. // (snapshot here is the value returned from getSnapshotBeforeUpdate) if (snapshot !== null) { const list = this.listRef.current; list.scrollTop = list.scrollHeight - snapshot; } } render() { return ( <div ref={this.listRef}>{/* ...contents... */}</div> ); }}

i eksemplene ovenfor er det viktig å lesescrollHeight egenskapen igetSnapshotBeforeUpdate fordi det kan være forsinkelser mellom «gjengi» fase livssykluser (somrender) og «forplikte» fase livssykluser (somgetSnapshotBeforeUpdateogcomponentDidUpdate).

Feilgrenser

Feilgrenser er React-komponenter som fanger JavaScript-feil hvor som helst i det underordnede komponenttreet, logger disse feilene og viser et reservegrensesnitt i stedet for komponenttreet som krasjet. Feilgrenser fanger feil under gjengivelse, i livssyklusmetoder og i konstruktører av hele treet under dem.

en klassekomponent blir en feilgrense hvis den definerer enten (eller begge) av livssyklusmetodene static getDerivedStateFromError()ellercomponentDidCatch(). Oppdatere tilstand fra disse livssyklusene kan du fange Opp en ubehandlet JavaScript-feil i under treet og vise en reserve UI.

bruk bare feilgrenser for å gjenopprette fra uventede unntak; ikke prøv å bruke dem til kontrollflyt.

hvis Du vil ha mer informasjon, kan Du se Feilhåndtering I React 16.

Merk

Feilgrenser fanger bare feil i komponentene under dem i treet. En feilgrense kan ikke fange en feil i seg selv.

statisk getDerivedStateFromError ()

static getDerivedStateFromError(error)

denne livssyklusen startes etter at en feil har blitt kastet av en etterkommer component.It mottar feilen som ble kastet som en parameter, og skal returnere en verdi for å oppdatere tilstanden.

class ErrorBoundary extends React.Component { constructor(props) { super(props); this.state = { hasError: false }; } static getDerivedStateFromError(error) { // Update state so the next render will show the fallback UI. return { hasError: true }; } render() { if (this.state.hasError) { // You can render any custom fallback UI return <h1>Something went wrong.</h1>; } return this.props.children; }}

Merk

getDerivedStateFromError() kalles under «gjengi» – fasen, så bivirkninger er ikke tillatt.For disse brukstilfellene, bruk componentDidCatch() i stedet.

componentDidCatch()

componentDidCatch(error, info)

denne livssyklusen startes etter at en feil har blitt kastet av en etterkommer component.It mottar to parametere:

1. error – feilen som ble kastet.
2. info – et objekt med en componentStack – nøkkel som inneholder informasjon om hvilken komponent som kastet feilen.

componentDidCatch() kalles under «commit» – fasen, så bivirkninger er permitted.It bør brukes til ting som logging feil:

class ErrorBoundary extends React.Component { constructor(props) { super(props); this.state = { hasError: false }; } static getDerivedStateFromError(error) { // Update state so the next render will show the fallback UI. return { hasError: true }; } componentDidCatch(error, info) { // Example "componentStack": // in ComponentThatThrows (created by App) // in ErrorBoundary (created by App) // in div (created by App) // in App logComponentStackToMyService(info.componentStack); } render() { if (this.state.hasError) { // You can render any custom fallback UI return <h1>Something went wrong.</h1>; } return this.props.children; }}

Produksjon og utvikling bygger Av React litt forskjellig i måtencomponentDidCatch()håndterer feil.

ved utvikling vil feilene boble opp til window, dette betyr at noen window.onerrorellerwindow.addEventListener('error', callback)vil fange opp feilene som har blitt fanget avcomponentDidCatch().

på produksjon, i stedet, feilene vil ikke boble opp, noe som betyr at noen stamfar feilbehandler vil bare motta feil ikke eksplisitt fanget av componentDidCatch().

Merk

i tilfelle en feil, kan du gjengi en reserve UI med componentDidCatch() ved å ringe setState, men dette vil bli foreldet i en fremtidig utgivelse.Bruk static getDerivedStateFromError() for å håndtere reservegjengivelse i stedet.

Metoder For Eldre Livssyklus

metodene for eldre Livssyklus nedenfor er merket som «eldre». De jobber fortsatt, men vi anbefaler ikke å bruke dem i den nye koden. Du kan lære mer om å migrere bort fra eldre livssyklusmetoder i dette blogginnlegget.

UNSAFE_componentWillMount ()

UNSAFE_componentWillMount()

UNSAFE_componentWillReceiveProps(nextProps)

UNSAFE_componentWillUpdate(nextProps, nextState)

setState(updater, )

(state, props) => stateChange

this.setState((state, props) => { return {counter: state.counter + props.step};});

stateogpropsmottatt av oppdateringsfunksjonen er garantert oppdatert. Utdataene fra oppdatereren slås sammen medstate.

den andre parameteren til setState() er en valgfri tilbakeringingsfunksjon som vil bli utført når setState er fullført og komponenten gjengis på nytt. Generelt anbefaler vi at du bruker componentDidUpdate() for slik logikk i stedet.

du kan eventuelt sende et objekt som det første argumentet til setState() i stedet for en funksjon:

setState(stateChange)

Dette utfører en grunne sammenslåing avstateChangetil den nye tilstanden, for eksempel for å justere en handlekurv varemengde:

this.setState({quantity: 2})

denne formen for setState() er også asynkron, og flere samtaler i samme syklus kan settes sammen. Hvis du for eksempel prøver å øke et vareantall mer enn en gang i samme syklus, vil det resultere i tilsvarende:

Object.assign( previousState, {quantity: state.quantity + 1}, {quantity: state.quantity + 1}, ...)

Etterfølgende anrop overstyrer verdier fra tidligere anrop i samme syklus, slik at antallet bare økes en gang. Hvis neste tilstand avhenger av gjeldende tilstand, anbefaler vi at du bruker oppdateringsfunksjonsskjemaet, i stedet:

this.setState((state) => { return {quantity: state.quantity + 1};});

for flere detaljer, se:

• Tilstand og Livssyklusguide
• i dybden: når og hvorfor er setState() samtaler batchet?
• i dybden: Hvorfor oppdateres ikkethis.state umiddelbart?

forceupdate ()

component.forceUpdate(callback)

når komponentens tilstand eller rekvisitter endres, vil komponenten din gjengis på nytt. Hvis render() – metoden avhenger av noen andre data, kan Du fortelle React at komponenten trenger re-rendering ved å ringe forceUpdate().

Kall forceUpdate() vil føre til render() å bli kalt på komponenten, hoppershouldComponentUpdate(). Dette vil utløse de normale livssyklusmetodene for barnekomponenter, inkludertshouldComponentUpdate() – metoden for hvert barn. React vil fortsatt bare oppdatere DOM hvis markeringen endres.

Normalt bør du prøve å unngå all bruk av forceUpdate() og bare lese fra this.props og this.state i render().

Class Properties

defaultProps

defaultProps kan defineres som en egenskap på komponentklassen selv, for å angi standard rekvisitter for klassen. This is used for undefined props, but not for null props. For example:

class CustomButton extends React.Component { // ...}CustomButton.defaultProps = { color: 'blue'};

If props.color is not provided, it will be set by default to 'blue':

 render() { return <CustomButton /> ; // props.color will be set to blue }

If props.color is set to null, it will remain null:

 render() { return <CustomButton color={null} /> ; // props.color will remain null }

displayName

The displayName string is used in debugging messages. Vanligvis trenger du ikke å angi det eksplisitt fordi det er utledet fra navnet på funksjonen eller klassen som definerer komponenten. Du vil kanskje angi det eksplisitt hvis du vil vise et annet navn for feilsøkingsformål, eller når du oppretter en høyere ordens komponent, kan du se Bryte Visningsnavnet For Enkel Feilsøking for detaljer.

Instansegenskaper

rekvisitter

this.props inneholder rekvisitter som ble definert av den som ringer denne komponenten. Se Komponenter og Rekvisitter for en introduksjon til rekvisitter.

spesielt this.props.children er en spesiell prop, vanligvis definert av underordnede koder I jsx-uttrykket i stedet for i selve taggen.

tilstand

tilstanden inneholder data som er spesifikke for denne komponenten, som kan endres over tid. Staten er brukerdefinert, og det bør være et vanlig JavaScript-objekt.

hvis noen verdi ikke brukes til gjengivelse eller dataflyt (for eksempel en timer-ID), trenger du ikke å sette den i tilstanden. Slike verdier kan defineres som felt på komponentforekomsten.

Se Tilstand og Livssyklus for mer informasjon om tilstanden.

mutere aldri this.state direkte, som ringer setState() etterpå kan erstatte mutasjonen du har gjort. Behandle this.state som om det var uforanderlig.