Como es solo una biblioteca, no dicta reglas sobre cómo debe organizar y estructurar sus proyectos. Esto es bueno, porque nos da la libertad de probar diferentes enfoques y adaptar los que mejor se adapten a nosotros. Por otro lado, esto podría generar cierta confusión para los desarrolladores que se inician en el mundo de . React React En esta publicación, mostraré algunos enfoques que he estado usando durante un tiempo y se han escalado muy bien. Estos enfoques no recrean la rueda, simplemente juntan y refinan lo que tenemos en el mercado. Recuerda: ¡Nada aquí está escrito en rocas! Puede tomar solo los enfoques que crea que tienen sentido y adaptarlos/cambiarlos para que encajen en su contexto. Estructura de carpetas Una de las preguntas que veo a menudo es sobre cómo estructurar archivos y carpetas. En esta publicación, estamos considerando que tiene una estructura mínima, como la creada con create-react-app. La aplicación create-react genera un proyecto básico para nosotros, que contiene en su raíz los archivos: , , , .gitignore package.json README.md yarn.lock También genera las carpetas: public y src. El último es donde guardamos nuestro código fuente. Echa un vistazo a la imagen de abajo, con la estructura descrita: En esta publicación, nos centraremos en la carpeta src. Todo lo que está fuera de eso, permanecerá intacto. Contenedores y Componentes Es probable que ya haya visto la separación entre y en la carpeta raíz de algún proyecto. quiero decir, dentro , tienes una carpeta llamada y otra carpeta llamada : Contenedores Componentes de presentación src components containers Sin embargo, este tipo de enfoque tiene algunos problemas, como puede ver a continuación: : no tiene reglas claras sobre qué es un y qué es un . La diferencia entre unos y otros puede ser subjetiva y cuando estás en un equipo, será difícil que todos los desarrolladores estén de acuerdo y juzguen por igual este asunto. Reglas subjetivas contenedor componente de presentación : incluso cuando decide que un componente encaja en uno de los tipos específicos, es fácil cambiarlo a lo largo de la vida del proyecto, convirtiéndose en otro tipo y obligándolo a moverlo de componentes a contenedores. carpeta y viceversa. No tiene en cuenta el dinamismo de los componentes - Los componentes deben tener nombres declarativos y únicos en la aplicación, para evitar confusiones sobre la responsabilidad de cada uno. Sin embargo, el enfoque anterior abre una brecha al tener dos componentes con el mismo nombre, uno que es un y otro que es de Permitir dos componentes con el mismo nombre contenedor presentación. debe navegar constantemente entre contenedores y carpetas de componentes, incluso cuando trabaja en una sola función. Porque es común que una sola característica tenga componentes de los dos tipos. Pérdida de productividad: También hay una variación de ese enfoque, que mantiene esta separación, pero dentro de los módulos. Imagina que dentro de tu aplicación tienes el módulo Usuario. En su interior, tendrías dos carpetas para separar tus componentes: El enfoque anterior minimiza el problema de navegar entre carpetas distantes en el árbol del proyecto. Sin embargo, añade mucho ruido. Dependiendo de cuántos módulos tenga su aplicación, terminará con docenas de contenedores y carpetas de componentes. Por esos motivos, cuando hablamos de organizar carpetas y archivos, es irrelevante dividir nuestros componentes por el concepto de frente a Que dicho vamos a mantener todos nuestros componentes dentro de la carpeta de componentes, excepto las . presentación contenedor. , pantallas Aun siendo irrelevante separarlos en carpetas, es importante conocer la diferencia conceptual entre uno y otro. Si aún tiene preguntas sobre este tema, le sugiero que lea el artículo: Componentes de presentación y contenedores. Separando y agrupando el código Dentro de la carpeta de componentes, agrupamos los archivos por módulo/característica. En un de usuario, solo tendríamos el módulo Usuario. Entonces, nuestra estructura sería la siguiente: CRUD Cuando un componente está compuesto por más de un archivo, colocamos este componente y sus archivos en una carpeta con el mismo nombre. Por ejemplo: supongamos que tiene un que contiene los En este caso, su estructura sería así: Form.css estilos de Form.jsx. Los archivos de prueba permanecen con el archivo que se está probando. En el caso anterior, la prueba para permanecería en su misma carpeta y se llamaría Form.jsx Form.spec.jsx Componentes de la interfaz de usuario Más allá de separar los componentes por módulos, también incluimos una carpeta UI dentro de src/components, para guardar todos nuestros componentes genéricos en ella. Los componentes de la interfaz de usuario son componentes lo suficientemente genéricos como para no pertenecer a un módulo. Son componentes que podría mantener en una biblioteca de código abierto, porque no tienen ninguna lógica comercial de la aplicación específica. Ejemplos de esos componentes son: botones, entradas, casillas de verificación, selecciones, modales, elementos de visualización de datos, etc. Nombrar componentes Arriba vimos cómo estructurar carpetas y separar nuestros componentes por módulos. Sin embargo, todavía hay una pregunta: ¿Cómo nombrarlos? Cuando hablamos de nombrar un componente, se trata del nombre que le damos a la o a la que define el componente: clase const { } MyComponent () => {}; class MyComponent extends Component const Como se mencionó anteriormente, el nombre que le demos a los componentes, debe ser claro y único en la aplicación, para que sean más fáciles de encontrar y evitar posibles confusiones. El nombre de un componente es muy útil cuando necesitamos depurar usando herramientas como y cuando ocurren errores de tiempo de ejecución en la aplicación. El error siempre viene con el nombre del componente donde ocurrió. React Dev Tools Para nombrar los componentes, seguimos el patrón que consiste en nombrar el componente de acuerdo a su ruta relativa a las carpetas components oa src, en el caso de que se encuentre fuera de la carpeta de componentes. Básicamente, un componente que se encuentra en: componentes/Usuario/ sería nombrado como . path-based-component-naming, List.jsx UserList Cuando el archivo está dentro de una carpeta con el mismo nombre, no necesitamos repetir el nombre. Dicho esto, componentes/Usuario/Formulario/ , sería nombrado como y no como . Form.jsx UserForm UserFormForm El patrón anterior tiene algunos beneficios que podemos ver a continuación: Facilitar la búsqueda del archivo dentro del proyecto Si su editor es compatible con la búsqueda difusa, simplemente busque el nombre UserForm para encontrar el archivo correcto: Si desea buscar el archivo en el árbol de carpetas, puede encontrarlo fácilmente simplemente orientándose por el nombre del componente: Evite repetir nombres en las importaciones Siguiendo el patrón, siempre nombrará el de acuerdo con su contexto. Teniendo en cuenta el anterior, sabemos que es un , pero como ya estamos dentro de la carpeta , no necesitamos repetir esa palabra en el nombre del del componente. Entonces, lo nombramos solo como archivo formulario formulario de usuario Usuario archivo Form.jsx Cuando comencé a trabajar con , solía poner el nombre completo en el archivo. Sin embargo, eso te hace repetir un nombre muchas veces y la ruta de importación se vuelve demasiado grande. Echa un vistazo a la diferencia entre los enfoques: React En el ejemplo anterior, no puede ver la ventaja de un enfoque a otro. Pero la aplicación crece un poco, es posible ver la diferencia. Mire el ejemplo a continuación, considerando un componente del proyecto en el que trabajo: Ahora imagine esto multiplicado por 5 o 10 veces en un solo archivo. Por esa razón, siempre nombramos el archivo de acuerdo con su contexto y el componente de acuerdo con su ubicación relativa a o carpeta. components src Pantallas Las pantallas, como ya indica el nombre, serían las pantallas que tenemos en la aplicación. En un de usuarios, tendríamos una pantalla para la lista de usuarios, una pantalla para crear un nuevo usuario y una pantalla para editar un usuario existente. CRUD Una pantalla es donde utiliza componentes para componer una página para la aplicación. Idealmente, la pantalla no contendría ninguna lógica y sería un componente funcional. Mantenemos las pantallas en una carpeta separada en la raíz de src, porque se agruparán de acuerdo con la definición de la ruta y no por módulos: Teniendo en cuenta que el proyecto usa , mantenemos el archivo dentro del carpeta, y definimos en ella todas las rutas de la aplicación. react-router Root.jsx screens El código para sería similar a este: Root.jsx React, { Component } ; { Router } ; { Redirect, Route, Switch } ; ScreensUserForm ; ScreensUserList ; ScreensRoot = ( <Switch> <Route path="/user/list" component={ScreensUserList} /> <Route path="/user/create" component={ScreensUserForm} /> <Route path="/user/:id" component={ScreensUserForm} /> </Switch> </Router> ); export default ScreensRoot; import from 'react' import from 'react-router' import from 'react-router-dom' import from './User/Form' import from './User/List' const => () < > Router Fíjate que ponemos todas las pantallas dentro de una carpeta con el mismo nombre de la ruta, usuario/ -> Usuario/. Trate de mantener una carpeta para cada ruta principal y agrupe las subrutas en ella. En este caso, creamos la carpeta Usuario y guardamos en ella la Lista de pantallas y el Formulario de pantalla. Este patrón te ayudará a encontrar fácilmente qué pantalla está representando cada ruta, simplemente echando un vistazo a la url. Se podría usar una sola pantalla para representar dos rutas diferentes, como hicimos anteriormente con las rutas para crear y editar un usuario. Puede notar que todos los componentes contienen la pantalla como prefijo en su nombre. Cuando el componente se encuentra fuera de la carpeta de componentes, debemos nombrarlo de acuerdo con su ruta relativa a la carpeta src. Un componente ubicado en src/screens/User/List.jsx debe llamarse ScreensUserList. Con el creado, nuestra estructura sería la siguiente: Root.jsx No olvide importar Root.jsx dentro de index.js para que sea el componente raíz de la aplicación. En caso de que aún tenga dudas sobre cómo debe verse una pantalla, eche un vistazo al ejemplo a continuación, para ver cuál sería la pantalla para el formulario de usuario. React ; UserForm ; ScreensUserForm = ( <h1> {`${!params.id ? 'Create' : 'Update'}`} User </h1> <UserForm id={params.id} /> </div> import from 'react' import from '../../components/User/Form/Form' const ( ) => { match: { params } } < > div ); export default ScreensUserForm; Finalmente, nuestra aplicación quedaría estructurada así: recapitulando Los componentes de y se mantienen en src/ presentación contenedor components Agrupe los componentes por módulo/característica. Mantenga los componentes genéricos dentro de src/ / components UI Mantenga las simples, con una estructura y un código mínimos. pantallas Agrupe las pantallas según la definición de la ruta. Para una ruta /usuario/lista tendríamos una pantalla ubicada en /src/screens/User/List.jsx. Los componentes se nombran de acuerdo con su ruta relativa a componentes o src. Dado eso, un componente ubicado en src/components/User/List.jsx se denominaría UserList. Un componente ubicado en src/screens/User/List se denominaría ScreensUserList. Los componentes que están en una carpeta con el mismo nombre, no repita el nombre en el componente. Teniendo en cuenta eso, un componente ubicado en src/components/User/List/List.jsx se denominaría UserList y UserListList. NO Conclusión Los consejos anteriores cubren solo una parte de la organización y estructura de un proyecto. Traté de mantenerlo solo sobre y dejar para una publicación futura. React Redux ¿Y usted? ¿Tienes algún enfoque que te gustaría compartir con nosotros? Escribe una respuesta a continuación, ¡me encantaría leer eso! ¿Disfrutaste la lectura? Ayúdanos a correr la voz dando un me gusta y compartiendo ️️️️ ❤️️ ¡No olvides seguirme para recibir notificaciones sobre futuras publicaciones!

Different

Keep

Read My Stories

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Making security fun one episode at a time

Estructuración de proyectos y nomenclatura de componentes en React

Demasiado Largo; Para Leer

Companies Mentioned

Vinicius Dacal

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

Estructuración de proyectos y nomenclatura de componentes en React

Demasiado Largo; Para Leer

Companies Mentioned

Vinicius Dacal

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS