Escribir una API para componentes React, parte 1: no cree accesorios conflictivos
Escribir una API para React Components, Parte 2: Dar nombres al comportamiento, no a la interacción
Escribir una API para componentes React, parte 3: el orden de los accesorios es importante
Escribir una API para React Components, Parte 4: ¡Cuidado con el Apropacalypse!
Escribir una API para React Components, Parte 5: solo use la composición
Escribimos API para componentes React, parte 6: creamos comunicación entre componentes
Esta publicación es una traducción del primer artículo de una serie de artículos de Writing API de componentes buenos , escrito por @Sid . Al traducir, en cualquier situación incomprensible, me guiaré por la traducción oficial de la documentación de React JS al ruso
Cuando se trata de componentes React, sus accesorios son su API.
Una buena API debe ser comprensible para que el propio desarrollador pueda descubrir cómo trabajar con ella. Esto se aplica no solo al desarrollo de bibliotecas de componentes, sino también al desarrollo de aplicaciones. Es importante que usted y su equipo se sientan cómodos usando componentes y sus API.
Esta serie de artículos está inspirada en artículos y conferencias de Sebastian Markbåge , Brent Jackson , Jenn Creighton y A. Jesse Jiryu Davis .
Después de leer muchos artículos + conferencias, y después de más de un año de diseño del diseño del sistema cosmos , llegué a estos principios de desarrollo.
Comencemos con uno simple.
Tenemos un botón:
<Button>Click me</Button>
También puede necesitar el botón principal, que es necesario para la acción principal en la página. Me gustaba construir la API, como si pudiera decir: "Dame el botón principal":
<Button>Click me</Button> <Button primary>Click me</Button>
Ahora, como suele ser el caso con los botones, necesitará algunas opciones más. Aquí hay una tabla de varios accesorios para botones:
Hay varios accesorios que puede usar para cambiar la apariencia de un botón. ¿Qué pasa si alguien los usa juntos?
<Button primary destructive> Click me </Button>
¿Alguno de ellos ganará? ¿De qué depende? De la orden?
¿Por qué alguien escribiría esto? ¿Hay un caso real cuando necesitas decir "Dame un botón destructive primary "?
En la mayoría de los casos esto es un error. Pero si los desarrolladores tienen que hacer tales preguntas (como las anteriores), probablemente esta no sea una API muy buena.
Para aquellos que deciden cuál será la API, es importante:
- minimizar errores
- minimizar la confusión en torno a la API
Así que aquí está el consejo # 1: no cree accesorios conflictivos.
Podemos arreglar fácilmente el código anterior usando prop que le permite obtener una lista de opciones. Llámalo appearance
<Button appearance="default">Click me</Button> <Button appearance="primary">Click me</Button> <Button appearance="destructive">Click me</Button>
Podemos agregar una lista de opciones compatibles para la appearance usando tipos de utilería .
Button.PropTypes = { appearance: PropTypes.oneOf(['default', 'primary', 'secondary', 'link', 'destructive']) }
Ahora, incluso si el desarrollador comete un error, recibirá una advertencia al respecto en su herramienta de desarrollo.
<Button appearance="danger">Click me</Button>
: : `prop` `appearance` `danger` `Button`, : `["default", "primary", "secondary", "link", "destructive"]`
Este consejo es bastante fácil de implementar, pero hará que su API sea mucho más fácil de usar (y compatible).
De un traductor: actualizaré la lista de artículos de esta serie (al principio) a medida que se traduzcan más artículos y haya nuevos disponibles.