No React, existem diferenças reais entre essas duas implementações? Alguns amigos me dizem que o FirstComponent é o padrão, mas não vejo o porquê. O SecondComponent parece mais simples porque a renderização é chamada apenas uma vez.
Primeiro:
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;
Segundo:
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;
Atualização: Alterei setState () para this.state = {} (obrigado joews). No entanto, ainda não vejo a diferença. Um é melhor que outro?
javascript
reactjs
components
Levy Moreira
fonte
fonte
this.state = { isVisible: props.isVisible }
faz sentido. Depende de como o aplicativo distribui o estado da interface do usuário.Respostas:
Note-se que é um anti-padrão copiar propriedades que nunca mudam para o estado (basta acessar .props diretamente nesse caso). Se você tiver uma variável de estado que mudará eventualmente, mas começa com um valor de .props, você nem precisa de uma chamada de construtor - essas variáveis locais são inicializadas após uma chamada ao construtor do pai:
Esta é uma abreviação equivalente à resposta de @joews abaixo. Parece funcionar apenas em versões mais recentes dos transpilers es6, tive problemas com ele em algumas configurações do webpack. Se isso não funcionar, tente adicionar o plug-in babel
babel-plugin-transform-class-properties
ou use a versão não abreviada de @joews abaixo.fonte
Você não precisa chamar
setState
um componenteconstructor
- é idiomático definirthis.state
diretamente:Consulte React docs - Adicionando estado local a uma classe .
Não há vantagem para o primeiro método que você descreve. Isso resultará em uma segunda atualização imediatamente antes da montagem do componente pela primeira vez.
fonte
setState
lo se o modificar em qualquer outro momento; caso contrário, as alterações poderão não ser renderizadas.super(props)
no construtor. Discussão sobre SOAtualização para o React 16.3 alpha introduzida
static getDerivedStateFromProps(nextProps, prevState)
( docs ) como um substituto paracomponentWillReceiveProps
.https://reactjs.org/docs/react-component.html#static-getderivedstatefromprops
É estático, portanto, não tem acesso direto a
this
(no entanto, tem acesso aprevState
, o que poderia armazenar coisas normalmente associadas a,this
por exemplorefs
)editado para refletir a correção de @ nerfologist nos comentários
fonte
getDerivedStateFromProps
(marcar a letra maiúscula em Props) e os parâmetros sãonextProps
,prevState
(nãonextState
): reactjs.org/docs/...getDerivedStateFromProps
sempre é chamado antes da renderização inicial?Você pode usar o formulário curto como abaixo se quiser adicionar todos os adereços ao estado e manter os mesmos nomes.
fonte
defina os dados do estado dentro do construtor como este
ele não funcionará se você definir o método side componentDidMount () por meio de adereços.
fonte
fonte
state = props
. Mais informações aqui: github.com/facebook/react/pull/11658#issuecomment-419677176você pode usar o
key
valor para redefinir o estado quando necessário, passar adereços para declarar que não é uma boa prática, porque você tem um componente descontrolado e controlado em um só lugar. Os dados devem estar em um único local, leia este https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a -chavefonte
Você pode usar componentWillReceiveProps.
fonte
É necessário ter cuidado ao inicializar a
state
partirprops
do construtor. Mesmo seprops
alterado para um novo, o estado não seria alterado porque a montagem nunca acontecerá novamente. EntãogetDerivedStateFromProps
existe para isso.fonte