reagera.Komponent

denna sida innehåller en detaljerad API-referens för definitionen av React component class. Det förutsätter att du är bekant med grundläggande React begrepp, såsom komponenter och rekvisita, samt tillstånd och livscykel. Om du inte är det, läs dem först.

översikt

React låter dig definiera komponenter som klasser eller funktioner. Komponenter definierade som klasser ger för närvarande fler funktioner som beskrivs i detalj på denna sida. För att definiera en React-komponentklass måste du utöka React.Component:

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

den enda metoden du måste definiera i en React.Componentunderklass kallas render(). Alla andra metoder som beskrivs på denna sida är valfria.

Vi rekommenderar starkt att du inte skapar egna baskomponentklasser. I React-komponenter uppnås kodåteranvändning främst genom komposition snarare än arv.

Obs:

React tvingar dig inte att använda ES6-klasssyntaxen. Om du föredrar att undvika det kan du istället använda create-react-class – modulen eller en liknande Anpassad abstraktion. Ta en titt på att använda React utan ES6 för att lära dig mer.

komponentens livscykel

varje komponent har flera” livscykelmetoder ” som du kan åsidosätta för att köra kod vid vissa tidpunkter i processen. Du kan använda detta livscykeldiagram som ett fuskark. I listan nedan markeras vanliga livscykelmetoder som fetstil. Resten av dem finns för relativt sällsynta användningsfall.

montering

dessa metoder kallas i följande ordning när en instans av en komponent skapas och sätts in i DOM:

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

Obs:

dessa metoder anses vara arv och du bör undvika dem i ny kod:

• UNSAFE_componentWillMount()

uppdatering

en uppdatering kan orsakas av ändringar i rekvisita eller tillstånd. Dessa metoder kallas i följande ordning när en komponent återges:

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

Obs:

dessa metoder anses vara äldre och du bör undvika dem i ny kod:

• UNSAFE_componentWillUpdate()
• UNSAFE_componentWillReceiveProps()

avmontering

denna metod kallas när en komponent tas bort från DOM:

• componentWillUnmount()

felhantering

dessa metoder kallas när det finns ett fel under rendering, i en livscykelmetod eller i konstruktören av någon barnkomponent.

• static getDerivedStateFromError()
• componentDidCatch()

andra API: er

varje komponent ger också några andra API: er:

• setState()
• forceUpdate()

klassegenskaper

• defaultProps
• displayName

instans egenskaper

• props
• state

referens

vanliga livscykelmetoder

metoderna i detta avsnitt täcker de stora de flesta användningsfall du kommer att stöta på att skapa react-komponenter. För en visuell referens, kolla in detta livscykeldiagram.

render ()

render()

render() metoden är den enda metod som krävs i en klasskomponent.

När den anropas bör den undersökathis.props ochthis.state och returnera en av följande typer:

• React elements. Vanligtvis skapas via JSX. Till exempel är<div /> och<MyComponent /> React-element som instruerar React att återge en DOM-nod eller en annan användardefinierad komponent.
• Arrays och fragment. Låt dig returnera flera element från render. Se dokumentationen om fragment för mer information.
• portaler. Låt dig göra barn till en annan DOM subtree. Se dokumentationen på portaler för mer information.
• sträng och siffror. Dessa återges som textnoder i DOM.
• Booleaner eller null. Gör ingenting. (Finns mestadels för att stödjareturn test && <Child /> mönster, därtest är booleskt.)

funktionenrender() ska vara ren, vilket innebär att den inte ändrar komponentstatus, den returnerar samma resultat varje gång den åberopas och den interagerar inte direkt med webbläsaren.

om du behöver interagera med webbläsaren, utför ditt arbete i componentDidMount() eller andra livscykelmetoder istället. Att hållarender() pure gör komponenter lättare att tänka på.

Obs

render()kommer inte att åberopas om shouldComponentUpdate() returnerar false.

konstruktör()

constructor(props)

om du inte initierar tillstånd och du inte binder metoder behöver du inte implementera en konstruktör för din React-komponent.

konstruktören för en React-komponent anropas innan den monteras. När du implementerar konstruktören för enReact.Component underklass, ska du ringasuper(props) före något annat uttalande. Annars kommer this.props att vara odefinierad i konstruktören, vilket kan leda till fel.

typiskt används i React konstruktörer endast för två ändamål:

• initiera lokalt tillstånd genom att tilldela ett objekt tillthis.state.
• bindande händelsehanteringsmetoder till en instans.

du ska inte ringa setState() I constructor(). Istället, om din komponent behöver använda lokalt tillstånd, tilldela initialtillståndet till this.state direkt 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 är den enda platsen där du ska tilldela this.state direkt. I alla andra metoder måste du använda this.setState() istället.

Undvik att införa några biverkningar eller prenumerationer i konstruktören. För dessa användningsfall, använd istället componentDidMount().

Obs

Undvik att kopiera rekvisita till tillstånd! Detta är ett vanligt misstag:

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

problemet är att det är både onödigt (Du kan använda this.props.color direkt istället) och skapar buggar (uppdateringar till color prop kommer inte att återspeglas i tillståndet).

använd bara det här mönstret om du avsiktligt vill ignorera prop-uppdateringar. I så fall är det vettigt att byta namn på Propen som ska kallas initialColor eller defaultColor. Du kan sedan tvinga en komponent att” återställa”sitt interna tillstånd genom att ändra dess key vid behov.

Läs vårt blogginlägg om att undvika härledd stat för att lära dig om vad du ska göra om du tror att du behöver något tillstånd att bero på rekvisita.

componentDidMount()

componentDidMount()

componentDidMount() anropas omedelbart efter att en komponent har monterats (infogats i trädet). Initialisering som kräver DOM-noder bör gå hit. Om du behöver ladda data från en fjärrslutpunkt är det här ett bra ställe att instansera nätverksförfrågan.

denna metod är ett bra ställe att ställa in några prenumerationer. Om du gör det, glöm inte att avsluta prenumerationen i componentWillUnmount().

Du kan ringa setState()omedelbart icomponentDidMount(). Det kommer att utlösa en extra rendering, men det kommer att hända innan webbläsaren uppdaterar skärmen. Detta garanterar att även om render() kommer att ringas två gånger i det här fallet, kommer användaren inte att se mellanläget. Använd detta mönster med försiktighet eftersom det ofta orsakar prestandaproblem. I de flesta fall bör du kunna tilldela det ursprungliga tillståndet i constructor() istället. Det kan dock vara nödvändigt för fall som modaler och verktygstips när du behöver mäta en DOM-nod innan du gör något som beror på dess storlek eller position.

componentDidUpdate ()

componentDidUpdate(prevProps, prevState, snapshot)

componentDidUpdate() anropas omedelbart efter uppdatering sker. Denna metod kallas inte för den ursprungliga renderingen.

använd detta som en möjlighet att arbeta på DOM när komponenten har uppdaterats. Detta är också ett bra ställe att göra nätverksförfrågningar så länge du jämför nuvarande rekvisita med tidigare rekvisita (t. ex. en nätverksförfrågan kanske inte är nödvändig om rekvisita inte har ändrats).

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

Du kan ringa setState() omedelbart i componentDidUpdate() men observera att det måste vara inslaget i ett tillstånd som i exemplet ovan, eller så orsakar du en oändlig slinga. Det skulle också orsaka en extra återgivning som, även om den inte är synlig för användaren, kan påverka komponentens prestanda. Om du försöker ”spegla” något tillstånd till en prop som kommer ovanifrån, överväg att använda prop direkt istället. Läs mer om varför kopiering av rekvisita till staten orsakar buggar.

om din komponent implementerargetSnapshotBeforeUpdate() livscykel (vilket är sällsynt) skickas värdet som den returnerar som en tredje ”snapshot” – parameter tillcomponentDidUpdate(). Annars kommer denna parameter att vara odefinierad.

Obs

componentDidUpdate()kommer inte att åberopas om shouldComponentUpdate() returnerar false.

componentWillUnmount()

componentWillUnmount()

componentWillUnmount() anropas omedelbart innan en komponent avmonteras och förstörs. Utför all nödvändig rengöring i den här metoden, till exempel ogiltigförklara timers, avbryta nätverksförfrågningar eller städa upp prenumerationer som skapades i componentDidMount().

du ska inte ringa setState() I componentWillUnmount() eftersom komponenten aldrig återges. När en komponentinstans är avmonterad kommer den aldrig att monteras igen.

sällan använda Livscykelmetoder

metoderna i detta avsnitt motsvarar ovanliga användningsfall. De är praktiska då och då, men de flesta av dina komponenter behöver förmodligen ingen av dem. Du kan se de flesta metoderna nedan i detta livscykeldiagram om du klickar på kryssrutan ”Visa mindre vanliga livscykler” högst upp i den.

shouldComponentUpdate ()

shouldComponentUpdate(nextProps, nextState)

använd shouldComponentUpdate() för att låta React veta om en komponents utgång inte påverkas av den aktuella förändringen i tillstånd eller rekvisita. Standardbeteendet är att återge vid varje tillståndsändring, och i de allra flesta fall bör du lita på standardbeteendet.

shouldComponentUpdate() anropas före rendering när nya rekvisita eller tillstånd tas emot. Standardvärdet är true. Denna metod kallas inte för den ursprungliga renderingen eller när forceUpdate() används.

denna metod finns bara som en prestandaoptimering. Lita inte på det för att ”förhindra” en rendering, eftersom det kan leda till buggar. Överväg att använda den inbyggda PureComponent istället för att skriva shouldComponentUpdate() för hand. PureComponent utför en ytlig jämförelse av rekvisita och tillstånd, och minskar risken för att du hoppar över en nödvändig uppdatering.

Om du är säker på att du vill skriva det för hand kan du jämföra this.props med nextProps och this.state med nextState och returnera false för att berätta react kan uppdateringen hoppas över. Observera att returfalse inte hindrar barnkomponenter från att återges när deras tillstånd ändras.

Vi rekommenderar inte att du gör djupa jämställdhetskontroller eller använder JSON.stringify() I shouldComponentUpdate(). Det är mycket ineffektivt och kommer att skada prestanda.

För närvarande, om shouldComponentUpdate() returnerar false, då UNSAFE_componentWillUpdate()render() och componentDidUpdate() kommer inte att åberopas. I framtiden kan React behandlashouldComponentUpdate() som en ledtråd snarare än ett strikt direktiv, och att returnerafalse kan fortfarande resultera i en återgivning av komponenten.

static getDerivedStateFromProps ()

static getDerivedStateFromProps(props, state)

getDerivedStateFromProps anropas direkt innan renderingsmetoden anropas, både på den ursprungliga monteringen och på efterföljande uppdateringar. Det bör returnera ett objekt för att uppdatera tillståndet, eller null för att uppdatera ingenting.

denna metod finns för sällsynta användningsfall där staten beror på förändringar i rekvisita över tiden. Det kan till exempel vara praktiskt att implementera en <Transition> – komponent som jämför sina tidigare och nästa barn för att bestämma vilka av dem som ska animeras in och Ut.

härleda tillstånd leder till verbose kod och gör dina komponenter svåra att tänka på.Se till att du är bekant med enklare alternativ:

• Om du behöver utföra en bieffekt (till exempel datahämtning eller en animering) som svar på en förändring av rekvisita, använd istället componentDidUpdate livscykel.
• Om du bara vill beräkna vissa data när en prop ändras, använd istället en memoiseringshjälpare.
• Om du vill ”återställa” något tillstånd när en prop ändras, överväga att antingen göra en komponent helt kontrollerad eller helt okontrollerad med ett key istället.

denna metod har inte tillgång till komponentinstansen. Om du vill kan du återanvända någon kod mellan getDerivedStateFromProps() och de andra klassmetoderna genom att extrahera rena funktioner för komponentrekvisita och tillstånd utanför klassdefinitionen.

Observera att denna metod avfyras på varje rendering, oavsett orsaken. Detta står i kontrast till UNSAFE_componentWillReceiveProps, som endast utlöses när föräldern orsakar en återgivning och inte som ett resultat av ett lokalt setState.

getSnapshotBeforeUpdate ()

getSnapshotBeforeUpdate(prevProps, prevState)

getSnapshotBeforeUpdate() åberopas precis innan den senast renderade produktionen har åtagit sig att t.ex. DOM. Det gör det möjligt för din komponent att fånga viss information från DOM (t.ex. rullningsposition) innan den eventuellt ändras. Alla värden som returneras av denna livscykel skickas som en parameter till componentDidUpdate().

detta användningsfall är inte vanligt, men det kan förekomma i UIs som en chattgänga som behöver hantera rullningspositionen på ett speciellt sätt.

ett ögonblicksvärde (eller null) ska returneras.

till exempel:

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 ovanstående exempel är det viktigt att läsa egenskapen scrollHeight I getSnapshotBeforeUpdate eftersom det kan finnas förseningar mellan ”render” – fasens livscykler (som render) och ”commit” fas livscykler (som getSnapshotBeforeUpdate och componentDidUpdate).

Felgränser

Felgränser är React-komponenter som fångar JavaScript-fel var som helst i deras underordnade komponentträd, loggar dessa fel och visar ett reservgränssnitt istället för komponentträdet som kraschade. Felgränser fångar fel under rendering, i livscykelmetoder och i konstruktörer av hela trädet under dem.

en klasskomponent blir en felgräns om den definierar antingen (eller båda) av livscykelmetoderna static getDerivedStateFromError() eller componentDidCatch(). Genom att uppdatera tillståndet från dessa livscykler kan du fånga ett ohanterat JavaScript-fel i nedanstående träd och visa ett reservgränssnitt.

använd endast Felgränser för att återhämta sig från oväntade undantag; försök inte använda dem för kontrollflöde.

För mer information, se felhantering i React 16.

Obs

Felgränser fångar bara fel i komponenterna under dem i trädet. En felgräns kan inte fånga ett fel i sig själv.

statisk getDerivedStateFromError ()

static getDerivedStateFromError(error)

denna livscykel åberopas efter att ett fel har kastats av en ättling component.It tar emot felet som kastades som en parameter och bör returnera ett värde för att uppdatera tillstånd.

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

Obs

getDerivedStateFromError() kallas under” render ” -fasen, så biverkningar är inte tillåtna.För dessa användningsfall, använd istället componentDidCatch().

componentDidCatch ()

componentDidCatch(error, info)

denna livscykel åberopas efter att ett fel har kastats av en ättling component.It tar emot två parametrar:

1. error – felet som kastades.
2. info – ett objekt med en componentStack nyckel som innehåller information om vilken komponent som kastade felet.

componentDidCatch() kallas under ”commit” – fasen, så biverkningar är permitted.It bör användas för saker som loggfel:

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-och utvecklingsbyggnader av React skiljer sig något i hur componentDidCatch() hanterar fel.

vid utveckling kommer felen att bubbla upp till window, det betyder att alla window.onerror eller window.addEventListener('error', callback) kommer att avlyssna de fel som har fångats av componentDidCatch().

på produktion kommer istället felen inte att bubbla upp, vilket innebär att någon förfader felhanterare endast får fel som inte uttryckligen fångas av componentDidCatch().

Obs

i händelse av ett fel kan du göra ett reservgränssnitt med componentDidCatch() genom att ringa setState, men detta kommer att avvecklas i en framtida utgåva.Använd static getDerivedStateFromError() för att hantera reservåtergivning istället.

Legacy Lifecycle Methods

livscykelmetoderna nedan är markerade som”legacy”. De fungerar fortfarande, men vi rekommenderar inte att du använder dem i den nya koden. Du kan lära dig mer om att migrera bort från äldre livscykelmetoder i det här blogginlägget.

UNSAFE_componentWillMount()

UNSAFE_componentWillMount()

Obs

denna livscykel har tidigare fått namnet componentWillMount. Det namnet kommer att fortsätta att fungera fram till version 17. Användrename-unsafe-lifecycles codemod för att automatiskt uppdatera dina komponenter.

UNSAFE_componentWillMount() anropas strax innan montering sker. Det kallas förerender(), därför ringersetState() synkront i denna metod kommer inte att utlösa en extra rendering. Generellt rekommenderar vi att du använder constructor() istället för att initiera tillstånd.

Undvik att införa några biverkningar eller prenumerationer i den här metoden. För dessa användningsfall, använd istället componentDidMount().

detta är den enda livscykelmetoden som kallas för serverrendering.

UNSAFE_componentWillReceiveProps()

UNSAFE_componentWillReceiveProps(nextProps)

UNSAFE_componentWillUpdate(nextProps, nextState)

setState(updater, )

(state, props) => stateChange

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

setState(stateChange)

this.setState({quantity: 2})

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

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

component.forceUpdate(callback)

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

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

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