reactjs - son - props react español

¿Es mejor definir el estado en el constructor o usar inicializadores de propiedades?

Question

De acuerdo con this documentación de Babel, la forma correcta de usar ES6 + con React es con componentes iniciales como este:

class Video extends React.Component {
static defaultProps = {
autoPlay: false,
maxLoops: 10,
}
static propTypes = {
autoPlay: React.PropTypes.bool.isRequired,
maxLoops: React.PropTypes.number.isRequired,
posterFrameSrc: React.PropTypes.string.isRequired,
videoSrc: React.PropTypes.string.isRequired,
}
state = {
loopsRemaining: this.props.maxLoops,
}
}

Pero algunos ejemplos oficiales, como el propio módulo React DnD de Dan Abramov, usan ES6 + pero aún definen el estado dentro del constructor:

constructor(props) {
super(props);
this.moveCard = this.moveCard.bind(this);
this.state = {
// state stuff
}
}

Ahora, Dan Abramov, siendo un contribuyente significativo a React, probablemente sabe que puede definir el estado fuera del constructor, pero aún así opta por hacerlo dentro del constructor.

Entonces, me pregunto qué camino es mejor y por qué.

Answer 1

Creo que es una cuestión de preferencia personal. La salida transpilada es la misma en términos de semántica.

• https://babeljs.io/repl/#?evaluate=true&lineWrap=false&presets=es2015%2Creact%2Cstage-1%2Cstage-2%2Cstage-3&experimental=false&loose=false&spec=false&code=class%20Video%20%7B%0A%20%20state%20%3D%20%7B%0A%20%20%20%20loopsRemaining%3A%20this.props.maxLoops%2C%0A%20%20%7D%0A%7D
• https://babeljs.io/repl/#?evaluate=true&lineWrap=false&presets=es2015%2Creact%2Cstage-1%2Cstage-2%2Cstage-3&experimental=false&loose=false&spec=false&code=class%20Video%20%7B%0A%20%20constructor()%20%7B%0A%20%20%20%20this.state%20%3D%20%7B%0A%20%20%20%20%20%20loopsRemaining%3A%20this.props.maxLoops%2C%0A%20%20%20%20%7D%0A%20%20%7D%0A%7D

Answer 2

Son equivalentes porque la propuesta de campo de clase es azúcar sintáctica para el código del cuerpo del constructor.

En caso de que no sea necesario un constructor explícito (creación de variables locales temporales, etc.), el constructor puede omitirse en favor de los campos de clase.

El problema con el constructor explícito es que los super argumentos ( props ) a menudo se omiten por error, esto puede ocasionar problemas:

constructor() {
super();
this.state = { foo: this.props.foo } // this.props is undefined
}

El constructor explícito puede ser beneficioso para la legibilidad. Los métodos se colocan debajo del constructor convencional, incluso las propiedades de flecha. Esto no funcionará según lo previsto porque los campos de clase se asignan en el orden en que se enumeraron:

state = { foo: { method: this.someMethod } } // this.someMethod is undefined
someMethod = () => ...;

En este caso, el constructor explícito puede generar un código más legible:

constructor(props) {
super(props);
// <-- this is the place where this.someMethod is really assigned
this.state = { foo: { method: this.someMethod } }
}
someMethod = () => ...;

Answer 3

El código de Dan en realidad tiene un error sutil, por eso recomiendo usar los inicializadores siempre que sea posible. Los constructores de componentes de reacción toman dos argumentos: los accesorios y el contexto . No lo está pasando al constructor principal y podría ser fácilmente perdido por algún otro desarrollador que lo necesitara.

A veces no tienes otra opción, como cuando el inicializador depende de los argumentos del constructor, así que solo recuerda pasar todos los argumentos al padre.

Después de intentar algunas cosas, parece que React no tiene el problema en el que estaba pensando. Puede pasar lo que quiera al constructor principal y estará bien. P.ej:

class MyComponent extends React.Component {
constructor(props) {
super({})
}
render() {
// this.props will still be set correctly here
}
}

Todavía recomiendo usar los inicializadores ya que no tener que llamar al constructor principal es una cosa menos en la que pensar.