Describimos estructura de archivos para componentes React: mejores prácticas, las cuales son útiles al momento de realizar proyectos front-end.
Estructura de archivos
Por lo general, cuando se habla de estructura de archivos, la discusión se centra en el proyecto como un todo. Pero lo que es igualmente de importante (y a menudo se pasa por alto) la forma de cómo estructurar mejor los componentes.
Directorio de componentes
Pueden tratarse como miniproyectos en sí mismos y son los componentes básicos de cada aplicación React, por lo que debe ser lo más autónomo posible (pero no más).
Un directorio de componentes típico podría verse así:
├── components
│ ├── Component
│ │ ├── SubComponent
│ │ │ ├── SubComponent.test.tsx
│ │ │ ├── index.tsx
│ │ ├── Component.stories.tsx
│ │ ├── Component.test.tsx
│ │ ├── icon.svg
│ │ ├── index.tsx
│ │ ├── utils.ts
│ │ ├── utils.test.ts
Archivo de índice principal
La exportación predeterminada de este archivo es el propio componente.
Además, el índice también podría incluir exportaciones con nombre. Por ejemplo, si estoy construyendo un componente-menú, se podría usar así:
import Menu, { MenuItem } from ‘components/Menu’
const ComponentWithMenu = () => {
return (
<Menu>
<MenuItem />
<MenuItem />
</Menu>
)
}
Entonces, en el archivo de índice, se requiere exportar Menu como la exportación predeterminada pero también volver a exportar el Menu-Item-subcomponente como una exportación con nombre, para después importar ambos desde el mismo lugar.
La reexportación también ayuda a documentar qué es público (y qué está destinado a ser utilizado por el resto de la aplicación) y qué es privado para el componente.
Pruebas
Los archivos que van juntos deben colaborar, ya que se puede contemplar el proceso de editar o incluso eliminar componentes.
Además, las pruebas suelen servir como documentación. Por lo tanto, tenerlos junto al componente tiene sentido.
Story
Storybook es una herramienta para desarrollar componentes de forma aislada, permite tratar los componentes como miniproyectos separados. Colocar cada historia con su componente correspondiente es importante por las mismas razones descritas anteriormente.
Estilos
Cuando se usa CSS-in-JS, los componentes con estilo se pueden crear directamente dentro del archivo de componentes. Si hemos optado por módulos CSS, los archivos de estilo deben colocarse con el componente en su directorio.
Activos
Las imágenes, los iconos u otros activos específicos del componente deben colocarse directamente en el directorio del componente.
Subcomponentes
Los subcomponentes están estructurados de manera muy similar al componente principal, ya que suelen ser utilizados por éste.
Si la intención es utilizarlos en toda la aplicación se deben volver a exportarse al archivo de índice principal. No debería ser posible utilizar los subcomponentes sin el componente principal.
Si este es el caso, entonces el subcomponente debería convertirse en un componente principal.
Los subcomponentes deben tener sus propias pruebas unitarias colocadas, estilos y activos. La mayoría de las veces, las historias se reservan solo para el componente principal.
Qué mantener fuera del directorio de componentes
Aquí hay una regla: si alguna vez se da la tentación de usar algo diferente a lo que se ha exportado explícitamente desde el índice del componente, es una señal de que este fragmento de código en particular debe colocarse en otro lugar.
Respecto al Menu-componente, se esperaría que si un usuario hace clic fuera de un menú, este debería cerrarse. Para hacer esto, se debe crear un gancho personalizado useClickOutsidey y colocarse en utils.
Después de un tiempo, queda claro que necesitamos exactamente el mismo comportamiento, esta vez para nuestro Dialogcomponente.
Se puede reutilizar el gancho pero, al mismo tiempo, ya no es un componente específico. Se debería sacarlo del componente Menú y colocarlo más arriba, tal vez en la carpeta de utilidades generales.
Hay que considerar que levantar el código para reutilizarlo debe hacerse con cuidado y solo cuando sea realmente necesario. Como desarrolladores, a se pueden crear abstracciones demasiado pronto y sin un contexto completo. Esto puede tener graves consecuencias para la sostenibilidad del proyecto en el futuro.
Muchas veces, si un fragmento de código hace algo similar (pero no exactamente lo mismo), es mejor replicar parte de la funcionalidad al principio y solo crear la abstracción cuando haya suficiente confianza en los casos de uso.
Leíste: Estructura de archivos para componentes React: mejores prácticas, te recomendamos: Cómo configurar una aplicación React con Parcel
Te invitamos a que nos sigas en nuestras redes sociales: Facebook, Twitter, Instagram y Youtube con el perfil: @tortugacode