reagere.Komponent

denne side indeholder en detaljeret API-reference for definitionen af React-komponentklasse. Det forudsætter, at du er bekendt med grundlæggende React-koncepter, såsom komponenter og rekvisitter, samt tilstand og livscyklus. Hvis du ikke er det, skal du læse dem først.

oversigt

React lader dig definere komponenter som klasser eller funktioner. Komponenter defineret som klasser giver i øjeblikket flere funktioner, som er beskrevet detaljeret på denne side. For at definere en React-komponentklasse skal du udvide React.Component:

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

den eneste metode, du skal definere i enReact.Componentunderklasse kaldes. Alle de andre metoder, der er beskrevet på denne side, er valgfri.

Vi anbefaler kraftigt mod at oprette dine egne basiskomponentklasser. I React-komponenter opnås kodegenbrug primært gennem sammensætning snarere end arv.

Bemærk:

React tvinger dig ikke til at bruge ES6-klassens syntaks. Hvis du foretrækker at undgå det, kan du bruge create-react-class modulet eller en lignende brugerdefineret abstraktion i stedet. Se på at bruge React uden ES6 for at lære mere.

komponentens livscyklus

hver komponent har flere “livscyklusmetoder”, som du kan tilsidesætte for at køre kode på bestemte tidspunkter i processen. Du kan bruge dette livscyklusdiagram som et snydeark. I listen nedenfor er almindeligt anvendte livscyklusmetoder markeret som fed. Resten af dem findes i relativt sjældne brugssager.

montering

disse metoder kaldes i følgende rækkefølge, når en forekomst af en komponent oprettes og indsættes i DOM:

• constructor()
• static getDerivedStateFromProps()
• componentDidMount()

bemærk:

disse metoder betragtes som arv, og du bør undgå dem i ny kode:

• UNSAFE_componentWillMount()

opdatering

en opdatering kan være forårsaget af ændringer i rekvisitter eller tilstand. Disse metoder kaldes i følgende rækkefølge, når en komponent gengives:

• static getDerivedStateFromProps()
• shouldComponentUpdate()
• getSnapshotBeforeUpdate()
• componentDidUpdate()

bemærk:

disse metoder betragtes som arv, og du bør undgå dem i ny kode:

• UNSAFE_componentWillUpdate()
• UNSAFE_componentWillReceiveProps()

afmontering

denne metode kaldes, når en komponent fjernes fra DOM:

• componentWillUnmount()

fejlhåndtering

disse metoder kaldes, når der er en fejl under gengivelse, i en livscyklusmetode eller i konstruktøren af enhver barnekomponent.

• static getDerivedStateFromError()
• componentDidCatch()

Andre API ‘er

hver komponent giver også nogle andre API’ er:

• setState()
• forceUpdate()

klasse egenskaber

• defaultProps
• displayName

instansegenskaber

• props
• state

reference

almindeligt anvendte livscyklusmetoder

metoderne i dette afsnit dækker langt de fleste brugssager, du vil støde på at oprette react-komponenter. For en visuel reference, tjek dette livscyklusdiagram.

render ()

render()

metoden er den eneste krævede metode i en klassekomponent.

når det kaldes, skal det undersøge this.propsog this.state og returnere en af følgende typer:

• React elements. Typisk oprettet via JS. For eksempel <div /> og <MyComponent /> er React-elementer, der instruerer React til at gengive henholdsvis en DOM-node eller en anden brugerdefineret komponent.
• Arrays og fragmenter. Lad dig returnere flere elementer fra render. Se dokumentationen om fragmenter for flere detaljer.
• portaler. Lad dig gøre børn til et andet DOM-undertræ. Se dokumentationen på portaler for flere detaljer.
• streng og tal. Disse gengives som tekstknudepunkter i DOM.
• Booleans ellernull. Gør ingenting. (For det meste eksisterer for at understøtte return test && <Child /> mønster, hvor test er boolsk.

render() funktionen skal være ren, hvilket betyder, at den ikke ændrer komponenttilstand, den returnerer det samme resultat hver gang det påberåbes, og det interagerer ikke direkte med bro.sereren.

Hvis du har brug for at interagere med bro.ser, skal du udføre dit arbejde i componentDidMount() eller de andre livscyklusmetoder i stedet. At holde render() pure gør komponenter lettere at tænke på.

Bemærk

vil ikke blive påberåbt, hvis shouldComponentUpdate() returnerer FALSK.

constructor()

constructor(props)

Hvis du ikke initialiserer tilstand, og du ikke binder metoder, behøver du ikke implementere en konstruktør til din React-komponent.

konstruktøren for en React-komponent kaldes, før den monteres. Når du implementerer konstruktøren for enReact.Component underklasse, skal du ringesuper(props) før enhver anden erklæring. Ellers this.props vil være udefineret i konstruktøren, hvilket kan føre til fejl.

typisk anvendes React-konstruktører kun til to formål:

• initialisering af lokal tilstand ved at tildele et objekt til this.state.
• bindende hændelseshåndteringsmetoder til en forekomst.

Du skal ikke ringesetState() iconstructor(). I stedet, hvis din komponent skal bruge lokal tilstand, skal du tildele den oprindelige tilstand 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);}

Constructor er det eneste sted, hvor du skal tildele this.state direkte. I alle andre metoder skal du bruge this.setState() i stedet.

undgå at indføre bivirkninger eller abonnementer i konstruktøren. I disse brugssager skal du bruge componentDidMount() i stedet.

Bemærk

undgå at kopiere rekvisitter til tilstand! Dette er en almindelig fejl:

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

problemet er, at det både er unødvendigt (du kan bruge this.props.color direkte i stedet) og opretter fejl (opdateringer til color prop afspejles ikke i staten).

brug kun dette mønster, hvis du med vilje vil ignorere prop-opdateringer. I så fald er det fornuftigt at omdøbe prop ‘ en til at blive kaldt initialColor eller defaultColor. Du kan derefter tvinge en komponent til at” nulstille”sin interne tilstand ved at ændre dens key når det er nødvendigt.

læs vores blogindlæg om at undgå afledt tilstand for at lære om, hvad du skal gøre, hvis du tror, du har brug for en tilstand, der er afhængig af rekvisitterne.

componentDidMount()

componentDidMount()

componentDidMount() påberåbes umiddelbart efter en komponent er monteret (indsat i træet). Initialisering, der kræver DOM-noder, skal gå her. Hvis du har brug for at indlæse data fra et eksternt slutpunkt, er dette et godt sted at instantiere netværksanmodningen.

denne metode er et godt sted at oprette abonnementer. Hvis du gør det, så glem ikke at afmelde dig componentWillUnmount().

Du kan ringesetState()straks icomponentDidMount(). Det vil udløse en ekstra gengivelse, men det vil ske, før bro.ser opdaterer skærmen. Dette garanterer, at selvom vil blive kaldt to gange i dette tilfælde, vil brugeren ikke se mellemtilstanden. Brug dette mønster med forsigtighed, fordi det ofte forårsager problemer med ydeevnen. I de fleste tilfælde skal du være i stand til at tildele den oprindelige tilstand i constructor() i stedet. Det kan dog være nødvendigt i tilfælde som modeller og værktøjstip, når du har brug for at måle en DOM-knude, før du gengiver noget, der afhænger af dens størrelse eller position.

componentDidUpdate ()

componentDidUpdate(prevProps, prevState, snapshot)

componentDidUpdate() påberåbes umiddelbart efter opdatering sker. Denne metode kaldes ikke for den oprindelige gengivelse.

Brug dette som en mulighed for at operere på DOM, når komponenten er blevet opdateret. Dette er også et godt sted at gøre netværksanmodninger, så længe du sammenligner de nuværende rekvisitter med tidligere rekvisitter (f. eks. en netværksanmodning er muligvis ikke nødvendig, hvis rekvisitterne ikke er ændret).

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 bemærk at det skal pakkes ind i en tilstand som i eksemplet ovenfor, eller du vil forårsage en uendelig sløjfe. Det ville også medføre en ekstra gengivelse, som, selvom den ikke er synlig for brugeren, kan påvirke komponentens ydeevne. Hvis du forsøger at “spejle” en tilstand til en prop, der kommer ovenfra, skal du overveje at bruge prop direkte i stedet. Læs mere om, hvorfor kopiering af rekvisitter til tilstand forårsager fejl.

Hvis din komponent implementerergetSnapshotBeforeUpdate() livscyklus (hvilket er sjældent), overføres den værdi, den returnerer, som en tredje “snapshot” – parameter tilcomponentDidUpdate(). Ellers vil denne parameter være udefineret.

Bemærk

componentDidUpdate()vil ikke blive påberåbt, hvis shouldComponentUpdate() returnerer FALSK.

komponentvilunmount()

componentWillUnmount()

componentWillUnmount() påberåbes umiddelbart før en komponent afmonteres og ødelægges. Udfør enhver nødvendig oprydning i denne metode, såsom ugyldiggørelse af timere, annullering af netværksanmodninger eller oprydning af abonnementer, der blev oprettet i componentDidMount().

Du skal ikke ringe setState()i componentWillUnmount() fordi komponenten aldrig gengives igen. Når en komponentinstans er afmonteret, monteres den aldrig igen.

sjældent anvendte Livscyklusmetoder

metoderne i dette afsnit svarer til usædvanlige brugssager. De er praktiske en gang imellem, men de fleste af dine komponenter har sandsynligvis ikke brug for nogen af dem. Du kan se de fleste af metoderne nedenfor i dette livscyklusdiagram, hvis du klikker på afkrydsningsfeltet “Vis mindre almindelige livscyklusser” øverst i det.

shouldComponentUpdate ()

shouldComponentUpdate(nextProps, nextState)

brugshouldComponentUpdate() for at lade React vide, om en komponents output ikke påvirkes af den aktuelle ændring i tilstand eller rekvisitter. Standardadfærden er at gengive hver tilstandsændring igen, og i langt de fleste tilfælde skal du stole på standardadfærden.

shouldComponentUpdate() påberåbes før gengivelse, når nye rekvisitter eller tilstand modtages. Standard true. Denne metode kaldes ikke for den oprindelige gengivelse, eller når forceUpdate() bruges.

denne metode findes kun som en ydelsesoptimering. Stol ikke på det for at “forhindre” en gengivelse, da dette kan føre til fejl. Overvej at bruge den indbyggede PureComponent i stedet for at skrive shouldComponentUpdate() for hånd. PureComponent udfører en lav sammenligning af rekvisitter og tilstand og reducerer chancen for, at du springer over en nødvendig opdatering.

Hvis du er sikker på, at du vil skrive det for hånd, kan du sammenligne this.props med nextProps og this.state med nextState og return false for at fortælle react kan opdateringen springes over. Bemærk, at returnering af false forhindrer ikke, at barnekomponenter gengives, når deres tilstand ændres.

Vi anbefaler ikke at foretage dyb ligestillingskontrol eller brugeJSON.stringify()ishouldComponentUpdate(). Det er meget ineffektivt og vil skade ydeevnen.

i øjeblikket, hvis shouldComponentUpdate() returnerer false, så UNSAFE_componentWillUpdate() og componentDidUpdate() vil ikke blive påberåbt. I fremtiden kan React behandle shouldComponentUpdate()som et tip snarere end et strengt direktiv, og returnering false kan stadig resultere i en gengivelse af komponenten.

statisk getderivedstatefrops ()

static getDerivedStateFromProps(props, state)

getDerivedStateFromProps påberåbes lige før du kalder gengivelsesmetoden, både på den oprindelige montering og på efterfølgende opdateringer. Det skal returnere et objekt for at opdatere staten, eller null for at opdatere ingenting.

denne metode findes i sjældne tilfælde, hvor staten afhænger af ændringer i rekvisitter over tid. For eksempel kan det være praktisk at implementere en <Transition> komponent, der sammenligner sine tidligere og næste børn for at beslutte, hvilken af dem der skal animere ind og ud.

afledt tilstand fører til verbose kode og gør dine komponenter vanskelige at tænke på.Sørg for, at du er fortrolig med enklere alternativer:

• hvis du har brug for at udføre en bivirkning (for eksempel dataindhentning eller en animation) som reaktion på en ændring i rekvisitter, skal du brugecomponentDidUpdate livscyklus i stedet.
• hvis du kun vil beregne nogle data igen, når en prop ændres, skal du bruge en memoiseringshjælper i stedet.
• hvis du vil “nulstille” en tilstand, når en prop ændres, skal du overveje enten at gøre en komponent fuldt kontrolleret eller fuldt ukontrolleret med en key i stedet.

denne metode har ikke adgang til komponentforekomsten. Hvis du vil, kan du genbruge noget kode mellem getDerivedStateFromProps() og de andre klassemetoder ved at udtrække rene funktioner i komponentrekvisitterne og tilstand uden for klassedefinitionen.

Bemærk, at denne metode fyres på hver gengivelse, uanset årsagen. Dette er i modsætning til UNSAFE_componentWillReceiveProps, som kun brænder, når forældrene forårsager en gengivelse og ikke som følge af en lokal setState.

getsnapshotforeupdate ()

getSnapshotBeforeUpdate(prevProps, prevState)

getSnapshotBeforeUpdate() påberåbes lige før den senest gengivne output er forpligtet til f.eks. DOM. Det gør det muligt for din komponent at fange nogle oplysninger fra DOM (f.eks. Enhver værdi, der returneres af denne livscyklus, overføres som en parameter til componentDidUpdate().

denne brugssag er ikke almindelig, men den kan forekomme i UI ‘ er som en chattråd, der skal håndtere rulleposition på en særlig måde.

en snapshot-værdi (ellernull) 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 ovenstående eksempler er det vigtigt at læse scrollHeight ejendom i getSnapshotBeforeUpdate fordi der kan være forsinkelser mellem “render” fase livscyklus (som render) og “commit” fase livscyklus (som getSnapshotBeforeUpdate og componentDidUpdate).

Fejlgrænser

Fejlgrænser er React-komponenter, der fanger JavaScript-fejl overalt i deres underordnede komponenttræ, logger disse fejl og viser et fallback-brugergrænseflade i stedet for det komponenttræ, der styrtede ned. Fejlgrænser fanger fejl under gengivelse, i livscyklusmetoder og i konstruktører af hele træet under dem.

en klassekomponent bliver en fejlgrænse, hvis den definerer enten (eller begge) af livscyklusmetodernestatic getDerivedStateFromError() ellercomponentDidCatch(). Opdatering tilstand fra disse livscyklus kan du fange en uhåndteret JavaScript fejl i nedenstående træ og vise en fallback UI.

brug kun Fejlgrænser til at gendanne fra uventede undtagelser; prøv ikke at bruge dem til kontrolstrøm.

For flere detaljer, se fejlhåndtering i React 16.

Bemærk

Fejlgrænser fanger kun fejl i komponenterne under dem i træet. En fejlgrænse kan ikke fange en fejl i sig selv.

statisk getDerivedStateFromError ()

static getDerivedStateFromError(error)

denne livscyklus påberåbes efter en fejl er blevet kastet af en efterkommer component.It modtager den fejl, der blev kastet som en parameter, og skal returnere en værdi for at opdatere tilstand.

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; }}

Bemærk

getDerivedStateFromError() kaldes under “render” -fasen, så bivirkninger er ikke tilladt.I disse brugssager skal du bruge componentDidCatch() i stedet.

componentDidCatch ()

componentDidCatch(error, info)

denne livscyklus påberåbes efter en fejl er blevet kastet af en efterkommer component.It modtager to parametre:

1. error – den fejl, der blev kastet.
2. info – et objekt med encomponentStack nøgle, der indeholder oplysninger om, hvilken komponent der kastede fejlen.

componentDidCatch() kaldes under “commit” – fasen, så bivirkninger er permitted.It skal bruges til ting som logging fejl:

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; }}

Produktions-og udviklingsbygninger af React er lidt forskellige i vejen componentDidCatch() håndterer fejl.

Ved udvikling vil fejlene boble op tilwindow, det betyder, at enhverwindow.onerrorellerwindow.addEventListener('error', callback)vil opfange de fejl, der er blevet fanget afcomponentDidCatch().

ved produktion vil fejlene i stedet ikke boble op, hvilket betyder, at enhver forfader fejlhandler kun modtager fejl, der ikke eksplicit er fanget af componentDidCatch().

Bemærk

i tilfælde af en fejl kan du gengive et fallback-brugergrænseflade medcomponentDidCatch()ved at kaldesetState, men dette vil blive udskrevet i en fremtidig udgivelse.Brug static getDerivedStateFromError() til at håndtere tilbagefaldsgengivelse i stedet.

Legacy Lifecycle Methods

livscyklusmetoderne nedenfor er markeret som”legacy”. De fungerer stadig, men vi anbefaler ikke at bruge dem i den nye kode. Du kan lære mere om at migrere væk fra ældre livscyklusmetoder i dette blogindlæg.

Unsafe_komponentmontering ()

UNSAFE_componentWillMount()

Bemærk

denne livscyklus blev tidligere navngivetcomponentWillMount. Dette navn vil fortsætte med at fungere indtil version 17. Brug rename-unsafe-lifecycles codemod til automatisk at opdatere dine komponenter.

UNSAFE_componentWillMount() påberåbes lige før montering sker. Det kaldes før render(), derfor kalder setState() synkront i denne metode vil ikke udløse en ekstra gengivelse. Generelt anbefaler vi at bruge constructor() i stedet for initialisering tilstand.

undgå at indføre bivirkninger eller abonnementer i denne metode. I disse brugssager skal du bruge componentDidMount() i stedet.

dette er den eneste livscyklusmetode, der kaldes servergengivelse.

Unsafe_componentveceiveprops ()

UNSAFE_componentWillReceiveProps(nextProps)

Bemærk

denne livscyklus blev tidligere navngivetcomponentWillReceiveProps. Dette navn vil fortsætte med at fungere indtil version 17. Brug rename-unsafe-lifecycles codemod til automatisk at opdatere dine komponenter.

Bemærk:

brug af denne livscyklusmetode fører ofte til fejl og uoverensstemmelser

• hvis du har brug for at udføre en bivirkning (for eksempel datahentning eller en animation) som svar på en ændring i rekvisitter, skal du bruge componentDidUpdate livscyklus i stedet.
• hvis du brugte componentWillReceiveProps til kun at beregne nogle data, når en prop ændres, skal du bruge en memoiseringshjælper i stedet.
• hvis du brugte componentWillReceivePropstil at “nulstille” en tilstand, når en prop ændres, skal du overveje enten at gøre en komponent fuldt kontrolleret eller fuldt ukontrolleret med en key i stedet.

for andre brugssager skal du følge anbefalingerne i dette blogindlæg om afledt tilstand.

UNSAFE_componentWillReceiveProps() påberåbes, før en monteret komponent modtager nye rekvisitter. Hvis du har brug for at opdatere tilstanden som svar på prop-ændringer (for eksempel for at nulstille den), kan du sammenligne this.props og nextProps og udføre tilstandsovergange ved hjælp af this.setState() i denne metode.

Bemærk, at hvis en overordnet komponent får din komponent til at gengive igen, kaldes denne metode, selvom rekvisitter ikke er ændret. Sørg for at sammenligne de aktuelle og næste værdier, hvis du kun vil håndtere ændringer.

React kalder ikke UNSAFE_componentWillReceiveProps() med indledende rekvisitter under montering. Det kalder kun denne metode, hvis nogle af komponentens rekvisitter muligvis opdateres. Opkald this.setState()udløser generelt ikke UNSAFE_componentWillReceiveProps().

Unsafe_komponentopdatering ()

UNSAFE_componentWillUpdate(nextProps, nextState)

Bemærk

denne livscyklus blev tidligere navngivetcomponentWillUpdate. Dette navn vil fortsætte med at fungere indtil version 17. Brug rename-unsafe-lifecycles codemod til automatisk at opdatere dine komponenter.

UNSAFE_componentWillUpdate() påberåbes lige før gengivelse, når nye rekvisitter eller tilstand modtages. Brug dette som en mulighed for at udføre forberedelse, før en opdatering finder sted. Denne metode kaldes ikke for den oprindelige gengivelse.

Bemærk, at du ikke kan ringe til this.setState()her; du bør heller ikke gøre noget andet (f.eks.

typisk kan denne metode erstattes afcomponentDidUpdate(). Hvis du læste fra DOM i denne metode (f.eks. for at gemme en rulleposition), kan du flytte denne logik til getSnapshotBeforeUpdate().

Bemærk

UNSAFE_componentWillUpdate()vil ikke blive påberåbt, hvis shouldComponentUpdate() returnerer FALSK.

Andre API ‘ er

I modsætning til livscyklusmetoderne ovenfor (som reagerer opkald til dig), er metoderne nedenfor de metoder, du kan ringe fra dine komponenter.

der er kun to af dem: setState() og forceUpdate().

setState ()

setState(updater, )

setState() forespørgsler ændrer komponenttilstanden og fortæller React, at denne komponent og dens børn skal gengives med den opdaterede tilstand. Dette er den primære metode, du bruger til at opdatere brugergrænsefladen som svar på hændelseshåndterere og serversvar.

tænk på setState() som en anmodning snarere end en øjeblikkelig kommando for at opdatere komponenten. For bedre opfattet ydeevne kan React forsinke det og derefter opdatere flere komponenter i et enkelt pass. React garanterer ikke, at statens ændringer anvendes straks.

setState() opdaterer ikke altid komponenten med det samme. Det kan batch eller udsætte opdateringen indtil senere. Dette gør læsning this.statelige efter at have ringet setState() en potentiel faldgrube. Brug i stedet componentDidUpdate eller a setState tilbagekald (setState(updater, callback)), som begge garanteres at skyde, efter at opdateringen er blevet anvendt. Hvis du har brug for at indstille tilstanden baseret på den forrige tilstand, skal du læse om argumentet updater nedenfor.

setState()vil altid føre til en gengivelse, medmindreshouldComponentUpdate()returnererfalse. Hvis der anvendes mutable objekter, og betinget gengivelseslogik ikke kan implementeres i shouldComponentUpdate(), kalder setState() kun når den nye tilstand adskiller sig fra den tidligere tilstand, undgår unødvendige gengivelser.

det første argument er en updater funktion med signaturen:

(state, props) => stateChange

state er en henvisning til komponenttilstanden på det tidspunkt, hvor ændringen anvendes. Det bør ikke muteres direkte. I stedet skal ændringer repræsenteres ved at opbygge et nyt objekt baseret på input fra state og props. Antag for eksempel, at vi ønskede at øge en værdi i tilstand med props.step:

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

beggestateogprops modtaget af opdateringsfunktionen garanteres at være opdateret. Udgangen af opdatereren er grundigt fusioneret med state.

den anden parameter til setState() er en valgfri tilbagekaldsfunktion, der udføres, når setState er afsluttet, og komponenten gengives igen. Generelt anbefaler vi at bruge componentDidUpdate() til sådan logik i stedet.

Du kan eventuelt videregive et objekt som det første argument til setState() i stedet for en funktion:

setState(stateChange)

dette udfører en lav fletning af stateChange i den nye tilstand, f.eks. for at justere en indkøbskurv varemængde:

this.setState({quantity: 2})

denne form for setState() er også asynkron, og flere opkald i samme cyklus kan batches sammen. For eksempel, hvis du forsøger at øge en varemængde mere end en gang i samme cyklus, vil det resultere i ækvivalent med:

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

efterfølgende opkald tilsidesætter værdier fra tidligere opkald i samme cyklus, så mængden øges kun en gang. Hvis den næste tilstand afhænger af den aktuelle tilstand, anbefaler vi at bruge opdateringsfunktionsformularen i stedet:

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

for flere detaljer, se:

• State and Lifecycle guide
• i dybden: hvornår og hvorfor ersetState() opkald batched?
• i dybden: Hvorfor er ikke this.state opdateret med det samme?

forceUpdate()

component.forceUpdate(callback)

Når din komponents tilstand eller rekvisitter ændres, gengives din komponent som standard. Hvis din render()-metode afhænger af nogle andre data, kan du fortælle React, at komponenten skal gengives ved at kalde forceUpdate().

opkald forceUpdate() vil forårsage at blive kaldt på komponenten, springe shouldComponentUpdate(). Dette vil udløse de normale livscyklusmetoder for barnekomponenter, herunder shouldComponentUpdate() – metoden for hvert barn. React vil stadig kun opdatere DOM, hvis markeringen ændres.

normalt bør du forsøge at undgå alle anvendelser afforceUpdate()og kun læse frathis.propsogthis.statei.

klasseegenskaber

defaultProps

defaultProps kan defineres som en egenskab på selve komponentklassen for at indstille standardrekvisitterne 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. Normalt behøver du ikke at angive det eksplicit, fordi det udledes af navnet på den funktion eller klasse, der definerer komponenten. Du vil måske angive det eksplicit, hvis du vil vise et andet navn til fejlfindingsformål, eller når du opretter en komponent med højere ordre, se pak visningsnavnet for nem fejlfinding for detaljer.

Instansegenskaber

rekvisitter

this.props indeholder rekvisitterne, der blev defineret af opkalderen af denne komponent. Se komponenter og rekvisitter for en introduktion til rekvisitter.

isærthis.props.children er en speciel prop, typisk defineret af barnemærkerne i udtrykket i stedet for i selve tagget.

tilstand

tilstanden indeholder data, der er specifikke for denne komponent, og som kan ændre sig over tid. Staten er brugerdefineret, og det skal være et almindeligt JavaScript-objekt.

hvis en værdi ikke bruges til gengivelse eller datastrøm (for eksempel et timer-ID), behøver du ikke at sætte den i tilstanden. Sådanne værdier kan defineres som felter på komponentforekomsten.

se tilstand og livscyklus for at få flere oplysninger om tilstanden.

mutere aldrig this.statedirekte, da du kalder setState() bagefter kan erstatte den mutation, du lavede. Behandle this.state som om det var uforanderligt.