Czy w React są jakieś rzeczywiste różnice między tymi dwiema implementacjami? Niektórzy znajomi mówią mi, że FirstComponent jest wzorem, ale nie rozumiem dlaczego. SecondComponent wydaje się prostszy, ponieważ renderowanie jest wywoływane tylko raz.
Pierwszy:
import React, { PropTypes } from 'react'
class FirstComponent extends React.Component {
state = {
description: ''
}
componentDidMount() {
const { description} = this.props;
this.setState({ description });
}
render () {
const {state: { description }} = this;
return (
<input type="text" value={description} />
);
}
}
export default FirstComponent;
Druga:
import React, { PropTypes } from 'react'
class SecondComponent extends React.Component {
state = {
description: ''
}
constructor (props) => {
const { description } = props;
this.state = {description};
}
render () {
const {state: { description }} = this;
return (
<input type="text" value={description} />
);
}
}
export default SecondComponent;
Aktualizacja: Zmieniłem setState () na this.state = {} (dzięki joews), Jednak nadal nie widzę różnicy. Czy jedno jest lepsze od drugiego?
javascript
reactjs
components
Levy Moreira
źródło
źródło
this.state = { isVisible: props.isVisible }
ma to sens. Zależy od tego, jak aplikacja dystrybuuje stan interfejsu użytkownika.Odpowiedzi:
Należy zauważyć, że jest to anty-wzorzec do kopiowania właściwości, które nigdy nie zmieniają się w stan (wystarczy w tym przypadku uzyskać dostęp do .props). Jeśli masz zmienną stanu, która ostatecznie się zmieni, ale zaczyna się od wartości z .props, nie potrzebujesz nawet wywołania konstruktora - te zmienne lokalne są inicjowane po wywołaniu konstruktora rodzica:
Jest to skrót odpowiadający odpowiedzi z @joews poniżej. Wydaje się, że działa tylko na nowszych wersjach transpilatorów es6, miałem problemy z niektórymi ustawieniami webpacka. Jeśli to nie zadziała, możesz spróbować dodać wtyczkę babel
babel-plugin-transform-class-properties
lub możesz użyć wersji nieskróconej przez @joews poniżej.źródło
Nie musisz wywoływać
setState
komponentuconstructor
- idiomatyczne jest ustawieniethis.state
bezpośrednio:Zobacz React docs - Dodawanie stanu lokalnego do klasy .
Pierwsza opisana metoda nie ma przewagi. Spowoduje to drugą aktualizację bezpośrednio przed montażem komponentu po raz pierwszy.
źródło
setState
jeśli zmutujesz go w innym miejscu, w przeciwnym razie zmiany mogą się nie renderować.super(props)
w konstruktorze. Dyskusja na temat SOAktualizacja dla React 16.3 alfa wprowadzona
static getDerivedStateFromProps(nextProps, prevState)
( dokumenty ) jako zamiennikcomponentWillReceiveProps
.https://reactjs.org/docs/react-component.html#static-getderivedstatefromprops
Jest statyczny, dlatego nie ma bezpośredniego dostępu do
this
(jednak ma dostęp doprevState
, który mógłby przechowywać rzeczy normalnie dołączonethis
nprefs
)edytowane w celu odzwierciedlenia korekty @ nerfologist w komentarzach
źródło
getDerivedStateFromProps
(oznacz dużą literę w rekwizytach), a parami sąnextProps
:prevState
(nienextState
): reaktjs.org/docs/…getDerivedStateFromProps
jest on zawsze wywoływany przed początkowym renderowaniem?Możesz użyć krótkiego formularza jak poniżej, jeśli chcesz dodać wszystkie rekwizyty do stanu i zachować te same nazwy.
źródło
ustaw dane stanu wewnątrz konstruktora w ten sposób
nie zadziała, jeśli zostanie ustawiony w bocznej metodzie componentDidMount () za pomocą rekwizytów.
źródło
źródło
state = props
. Więcej informacji tutaj: github.com/facebook/react/pull/11658#issuecomment-419677176możesz użyć
key
wartości, aby zresetować stan w razie potrzeby, przekazać rekwizyty do stanu, który nie jest dobrą praktyką, ponieważ masz niekontrolowany i kontrolowany komponent w jednym miejscu. Dane powinny być obsługiwane w jednym miejscu, przeczytaj to https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a -kluczźródło
Możesz użyć componentWillReceiveProps.
źródło
MUSISZ BYĆ OSTROŻNY podczas inicjalizacji
state
z poziomuprops
konstruktora. Nawet jeśli zostanieprops
zmieniony na nowy, stan nie zostanie zmieniony, ponieważ mount nigdy się nie powtórzy. Tak więcgetDerivedStateFromProps
istnieje.źródło