Écriture d'une API pour les composants React, partie 1: ne créez pas d'accessoires conflictuels
Écriture d'une API pour les composants React, partie 2: donner des noms au comportement, pas à l'interaction
Écriture d'une API pour les composants React, partie 3: l'ordre des accessoires est important
Écriture d'une API pour React Components, Partie 4: Méfiez-vous de l'Apropacalypse!
Écriture d'une API pour les composants React, partie 5: il suffit d'utiliser la composition
Nous écrivons API pour les composants React, partie 6: nous créons la communication entre les composants
Cet article est une traduction du premier article d'une série d'articles de l' API Writing good component , rédigé par @Sid . Lors de la traduction, dans toute situation incompréhensible, je serai guidé par la traduction officielle de la documentation React JS en russe
En ce qui concerne les composants React, vos accessoires sont votre API.
Une bonne API doit être compréhensible pour que le développeur lui-même puisse comprendre comment l'utiliser. Cela s'applique non seulement au développement de bibliothèques de composants, mais également au développement d'applications. Il est important que vous et votre équipe soyez à l'aise avec les composants et leurs API.
Cette série d'articles est inspirée d'articles et de conférences de Sebastian Markbåge , Brent Jackson , Jenn Creighton et A. Jesse Jiryu Davis .
Après avoir lu de nombreux articles et conférences, et après plus d'un an de conception de la conception du système cosmos , je suis arrivé à ces principes de développement.
Commençons par un simple.
Nous avons un bouton:
<Button>Click me</Button>
Vous pouvez également avoir besoin du bouton principal, qui est nécessaire pour l'action principale sur la page. J'aimais construire l'API, comme si je pouvais dire - "Donnez-moi le bouton principal":
<Button>Click me</Button> <Button primary>Click me</Button>
Maintenant, comme c'est généralement le cas avec les boutons, vous aurez besoin de quelques options supplémentaires. Voici un tableau de plusieurs accessoires pour les boutons:
Il existe plusieurs accessoires que vous pouvez utiliser pour modifier l'apparence d'un bouton. Que se passe-t-il si quelqu'un les utilise ensemble?
<Button primary destructive> Click me </Button>
Est-ce que certains gagneront? De quoi cela dépend-il? De la commande?
Pourquoi voudrait-on écrire ça? Existe-t-il un cas réel où vous devez dire "Donnez-moi un bouton destructive primary "?
Dans la plupart des cas, c'est une erreur. Mais si les développeurs doivent poser de telles questions (comme celles ci-dessus), ce n'est probablement pas une très bonne API.
Pour ceux qui décident de ce que sera l'API, il est important:
- minimiser les erreurs
- minimiser la confusion autour de l'API
Voici donc le conseil n ° 1: ne créez pas d'accessoires conflictuels.
Nous pouvons assez facilement corriger le code ci-dessus en utilisant prop qui vous permet d'obtenir une liste d'options. Appelez ça l' appearance
<Button appearance="default">Click me</Button> <Button appearance="primary">Click me</Button> <Button appearance="destructive">Click me</Button>
Nous pouvons ajouter une liste des options d' appearance prises en charge à l'aide de prop-types .
Button.PropTypes = { appearance: PropTypes.oneOf(['default', 'primary', 'secondary', 'link', 'destructive']) }
Maintenant, même si le développeur fait une erreur, il recevra un avertissement à ce sujet dans son outil de développement.
<Button appearance="danger">Click me</Button>
: : `prop` `appearance` `danger` `Button`, : `["default", "primary", "secondary", "link", "destructive"]`
Cette astuce est assez facile à mettre en œuvre, mais elle rendra votre API beaucoup plus facile à utiliser (et à prendre en charge).
D'un traducteur - je mettrai à jour la liste des articles de cette série (au début) à mesure que d'autres articles seront traduits et que de nouveaux seront disponibles.