Estructuración de aplicaciones web React.js​ | por Dmitri | Archie.AI

Un mejor sistema de organización de archivos y nombres

La maldición y el regalo de React.js es el hecho de que no es obstinado en términos de cómo estructura sus componentes y archivos. Haz lo que quieras y funcionará. Pero con cada nuevo proyecto es un problema de «pizarra en blanco».

Este artículo está escrito desde la perspectiva de una persona que construye (y finalmente refactoriza) el front-end de una plataforma de blogs diseñada para entusiastas de la fotografía cinematográfica. Además de enumerar y mostrar artículos, la aplicación proporciona controles de administración y un paquete editorial completo de texto enriquecido, compuesto por 280 archivos y carpetas. La aplicación en cuestión es Café.analógico.

- app/
- components/
- containers/

Cuando comencé a trabajar en mi aplicación, luego de un año intensivo con compilaciones de Ruby on Rails para Archie.AI (un marco bastante obstinado) Me he topado con la pared tratando de descubrir cómo estructurar y nombrar los numerosos archivos con React. El consejo más común en ese momento era segregar los componentes en funciones puras y componentes con estado.

La expectativa con este método es que sus componentes inevitablemente se reutilizarán en otro lugar. Aunque esto puede ser cierto para muchos proyectos, no veo cómo podría ser el caso para todas las aplicaciones. Además, separar la funcionalidad y colocar las piezas de un componente que realiza la misma función en rincones separados de su sistema de archivos es contraproducente y contrario a la intuición.

Con un poco de experimentación he encontrado un mejor sistema (abajo).

​componentes con estilo es mi biblioteca preferida cuando se trata de integrar CSS en proyectos de React. Es muy bueno.

Un patrón común de uso es separar los estilos en styles.jsuna reminiscencia de la estructura de archivos que solíamos tener con archivos HTML escritos a mano más simples no hace mucho tiempo.

Resulta que esto no es una buena idea en la práctica. Es decir, porque este método crea un tercer tipo de componente (además de los inteligentes y tontos mencionados anteriormente). Lo que es peor, este tipo de componente tiene un método organizativo completamente separado, que intenta imitar paradigmas en conflicto.

Recomiendo tratar los componentes con estilo tal como son: componentes React.

El patrón de interfaz es un recordatorio de que estamos creando una aplicación frontal, que es más fácil de entender y estructurar cuando se considera como una compilación de elementos de interfaz visual. Este patrón consiste en sugerencias sobre estructura de archivos y carpetas, tipos de exportación preferidos, prácticas de comentarios y recomendaciones de tamaño de archivo.

- app/
- core/
- admin/
- user/
- constants.js
- index.js
- store.js
- utils.js

Nota: puede navegar por toda la estructura de la aplicación para Analog.Cafe en este repositorio.

Mi aplicación se divide en tres principales secciones: core/ admin/ y user/. En tu caso, es posible que no tengas ninguna sección si la aplicación no es lo suficientemente grande. Entonces puedes estructurar tu app/ carpeta al igual que el contenido de las secciones anteriores (ver más abajo).

Los cuatro archivos JavaScript anteriores deberían explicarse por sí mismos, pero con algunas advertencias. En este ejemplo, sirven como archivos de índice, donde almacenan solo las exportaciones más básicas y de uso común: index.js contiene el componente React contenedor principal para la aplicación, store.js combina los reductores que se encuentran dentro de las tres secciones de aplicación anteriores y exporta una tienda Redux, mientras que utils.js y constants.js contienen los fragmentos de función JavaScripit más comunes y las constantes reutilizables.

- core/
- components/
- constants/
- store/
- utils/

Dentro de cada una de las secciones de la aplicación hay cuatro carpetas que se asemejan a la forma de la app/ directorio. La única diferencia es que esta forma te obliga a crear más archivos en tu utils/y constants/carpetas que es mejor para la organización y también debería hacer que sacudir árboles funcione mejor.

Si no está dividiendo su aplicación en secciones las carpetas anteriores se pueden colocar dentro de su app/ carpeta, en lugar de core/.

- constants/
- messages-.js
- messages-article.js
- routes-article.js
- rules-submission.js
- utils/
- actions-session.js
- messages-profile.js

Ambos constants/y utils/ las carpetas tienen patrones similares de nomenclatura de archivos. La primera palabra clave es mensajes, rutas, reglas o acciones. Seguido de un guión y una palabra clave que describe una parte específica de la vista de su aplicación. Entiendo que esta no es la convención de nomenclatura más infalible, sin embargo, es posible que pueda entenderla mucho mejor en la práctica. Los principales objetivos deben ser consistencia y claridad.

Tenga en cuenta el archivo llamado mensajes-.js que contiene cadenas y objetos designados como mensajes para el usuario, no asignados a ninguna parte específica de la vista de la aplicación.

- store/
- actions-article.js
- actions-submission.js
- reducers-article.js
- reducers-submission.js

Él store/ La carpeta es para Redux. Contiene pares de archivos (acciones y reductores) para cada parte de la vista de su aplicación. Simple; todo en un lugar.

- components/
- controls/
- icons/
- pages/
- routes/
- forms/
- vignettes/

components/ carpeta: Encontré que los seis tipos de componentes anteriores son una forma bastante inclusiva de organizar una aplicación. Es necesario tener tales subcarpetas para encontrar rápidamente lo que está buscando y comprender la estructura de la aplicación. De lo contrario, es posible que se quede con cientos de carpetas en esta parte de su aplicación. Así los distingo:

controls/ — Botones y matrices de botones, cuadros modales, enlaces, barras de navegación, menús, etc.

icons/ — Elementos gráficos hechos con React y destinados a permanecer como parte de una aplicación, como SVG o CSS integrales.

pages/ — Componentes destinados a ocupar la totalidad o una parte significativa de un espacio de pantalla.

routes/ — Esta carpeta es específicamente para componentes de ruta de React Router.

forms/ — Elementos de entrada.

vignettes/ — Componentes más pequeños que no pertenecen a ningún otro lugar.

- controls/
- Card/
- index.js
- components/
- CardFigure.js
- CardHeader.js

Cada una de las carpetas de componentes tendría nombres escritos en CamelCase, con un opcional index.js en su raíz, que uniría todo. Si necesario, components/ La carpeta podría colocarse dentro, que puede contener componentes con estilo o componentes React.js que ayudarían directamente a componer el componente principal (en este caso, Card/ componente).

Nota 1: No hay distinción ni regla aquí entre los componentes «inteligentes» y «tontos», pero los componentes «inteligentes» naturalmente tienden a terminar en la raíz del componente principal en index.js, que podría usar para tu ventaja

Nota 2: No hay nada que le impida importar desde archivos ubicados en otras secciones de la aplicación; muchas veces es necesario y no hay nada de malo en ello. Siéntase libre de requerir admin/ útiles en su core/ componentes

Nota 3: Es posible que haya notado que los subcomponentes no tienen sus propias carpetas. Eso facilita la legibilidad y una mejor estructura de carpetas. Por supuesto, podrían colocarse en sus propias carpetas si a su vez tienen sus propios subcomponentes, pero eso sería complicado. Trate de mantener su árbol de archivos lo más plano posible.

Una regla simple es preferir exportaciones con nombre me gusta export const function Name ()=> en constants/ utils/ y store/ – esto lo alentará a equilibrar bien la cantidad de archivos en esas carpetas.

Sin embargo, todos los componentes deben esforzarse por exportar solo exportaciones predeterminadas con algunas excepciones en las que podrían contener exportaciones predeterminadas y con nombre en archivos muy pequeños. Esta regla simple lo obligará a crear más componentes (que, por cierto, son mucho más fáciles de nombrar que estructuras más rígidas). constantes y útiles archivos), lo que a su vez creará una serie de beneficios en términos del tamaño final del paquete y la legibilidad de la aplicación (menos líneas de código por archivo).

No más de 300 líneas por archivo. Cualquier cosa más grande que eso justifica dividirlo.

Solía ​​pensar que más comentarios en el código es mejor. Hasta que aprendí lo contrario. Muchos comentarios pueden ser útiles al crear un tutorial, sin embargo, tienden a contaminar los archivos de la aplicación y fomentan malas prácticas de nomenclatura de variables. Entonces, si el código parece difícil de entender, debe revisarse y corregirse para obtener nombres y estilos más comprensibles. Utiliza herramientas como más bonita a tu favor

Escriba código legible en lugar de algo que necesita un manual.