Voici comment je le fais depuis un certain temps:
export default class AttachmentCreator extends Component {
render() {
return <div>
<RaisedButton primary label="Add Attachment" />
</div>
}
}
AttachmentCreator.propTypes = {
id: PropTypes.string,
};
Mais j'ai vu des gens le faire de cette façon:
export default class AttachmentCreator extends Component {
static propTypes = {
id: PropTypes.string,
};
render() {
return <div>
<RaisedButton primary label="Add Attachment" />
</div>
}
}
Et en fait, j'ai vu des personnes définir également l'état initial en dehors du constructeur. Est-ce une bonne pratique? Cela me dérange, mais je me souviens d'une discussion quelque part où quelqu'un a dit que définir des accessoires par défaut comme une statique n'était pas une bonne idée - je ne me souviens pas pourquoi.
les propriétés non fonctionnelles ne sont actuellement pas prises en charge pour les classes es2015. c'est une proposition pour es2016. la seconde méthode est considérablement plus pratique, mais un plugin serait nécessaire pour supporter la syntaxe ( il s'agit d'un plugin babel très courant pour cela ).
D'un autre côté, de nombreux projets open source commencent à traiter des propriétés telles que les interfaces TypeScript ou ActionConstants et créent en fait des dossiers/fichiers distincts qui hébergent différents types d'accessoires de composant et sont ensuite importés dans le composant.
Donc, en résumé, les deux syntaxes sont acceptables. mais si vous voulez uniquement utiliser strictement ES2015, cette dernière syntaxe n'est pas encore prise en charge dans la spécification.
En fait, c'est exactement la même chose en termes de performance. React.JS est une technologie relativement nouvelle, donc on ne sait pas encore ce qui est considéré ou non comme une bonne pratique. Si vous voulez faire confiance à quelqu'un, consultez le guide-style de cette 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;
Ils déclarent un const avec les littéraux d'objet propTypes, gardent la classe assez propre et les assignent plus tard aux propriétés statiques. Personnellement, j'aime bien cette approche :)
class DataLoader extends React.Component {
static propTypes = {
onFinishedLoading: PropTypes.func
}
static defaultProps = {
onFinishedLoading: () => {}
}
}
... comme il est transpilé à cela de toute façon.
class DataLoader extends React.Component {}
DataLoader.propTypes = {
onFinishedLoading: PropTypes.func
};
DataLoader.defaultProps = {
onFinishedLoading: () => {}
};
Les champs statiques sont convertis en propriétés de classe sous le capot . Regardez ici Babel REPL.
De plus, l'affectation de state ou d'autres champs de classe directement dans la classe est transpilée en un constructeur d'instance.
Si le composant n'a pas d'état, ce qui signifie qu'il ne change pas du tout son propre état, vous devez le déclarer en tant que composant sans état (export default function MyComponent(props)
) et déclarer la propTypes
en dehors.
Que ce soit une bonne pratique de mettre la déclaration d'état initiale dans le constructeur dépend de vous. Dans notre projet, nous déclarons l'état initial dans componentWillMount()
simplement parce que nous n'aimons pas le comportement super(props)
que vous devez utiliser avec le constructeur.