react proptypes node defaultprops class reactjs ecmascript-next

class - proptypes - defaultprops react



¿Está bien poner propTypes y defaultProps como objetos estáticos dentro de la clase React? (4)

Oh sí, es totalmente legítimo con Babel

class DataLoader extends React.Component { static propTypes = { onFinishedLoading: PropTypes.func } static defaultProps = { onFinishedLoading: () => {} } }

... como se traslada a esto de todos modos.

class DataLoader extends React.Component {} DataLoader.propTypes = { onFinishedLoading: PropTypes.func }; DataLoader.defaultProps = { onFinishedLoading: () => {} };

Los campos estáticos se trasplantan como propiedades de clase bajo el capó. Mira aquí en Babel REPL.

Además, la asignación de campos de estado u otra clase directamente en la clase se transpila en un constructor de instancia .

Así lo he estado haciendo desde hace bastante tiempo:

export default class AttachmentCreator extends Component { render() { return <div> <RaisedButton primary label="Add Attachment" /> </div> } } AttachmentCreator.propTypes = { id: PropTypes.string, };

Pero he visto a la gente hacerlo de esta manera:

export default class AttachmentCreator extends Component { static propTypes = { id: PropTypes.string, }; render() { return <div> <RaisedButton primary label="Add Attachment" /> </div> } }

Y, de hecho, también he visto a personas establecer un estado inicial fuera del constructor. ¿Es esta buena práctica? Me ha estado molestando, pero recuerdo una discusión en algún lugar donde alguien dijo que establecer accesorios predeterminados como estática no es una buena idea, simplemente no recuerdo por qué.


De hecho, es exactamente lo mismo en términos de rendimiento. React.JS es una tecnología relativamente nueva, por lo que aún no está claro qué se consideran buenas prácticas o no. Si desea confiar en alguien, consulte la guía de estilo de AirBNB:

https://github.com/airbnb/javascript/tree/master/react#ordering

import React, { PropTypes } from ''react''; const propTypes = { id: PropTypes.number.isRequired, url: PropTypes.string.isRequired, text: PropTypes.string, }; const defaultProps = { text: ''Hello World'', }; class Link extends React.Component { static methodsAreOk() { return true; } render() { return <a href={this.props.url} data-id={this.props.id}>{this.props.text}</a> } } Link.propTypes = propTypes; Link.defaultProps = defaultProps; export default Link;

Están declarando una constante con los literales de objetos propTypes, mantienen la clase bastante limpia y les asignan más adelante las propiedades estáticas. Personalmente me gusta este enfoque :)


Si el componente no tiene estado, lo que significa que no cambia su propio estado, debe declararlo como un componente sin estado ( export default function MyComponent(props) ) y declarar los propTypes fuera.

Si es una buena práctica poner la declaración de estado inicial en el constructor, depende de usted. En nuestro proyecto, declaramos el estado inicial en componentWillMount() solo porque no nos gustan los super(props) que tiene que usar con el constructor.


las propiedades no funcionales no son compatibles actualmente para las clases de es2015. Es una propuesta para es2016. el segundo método es considerablemente más conveniente, pero se necesitaría un complemento para admitir la sintaxis ( hay un complemento babel muy común para él ).

En el otro extremo, una mano llena de proyectos de código abierto están comenzando a tratar los tipos como las interfaces TypeScript o ActionConstants y, de hecho, crean carpetas / archivos separados que albergan varios tipos de accesorios y luego se importan al componente.

Así que en resumen, ambas sintaxis están bien de usar. pero si solo desea usar estrictamente ES2015, la última sintaxis aún no es compatible con la especificación.