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!

Estructuración de proyectos y nomenclatura de componentes en React

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

El modelo Bitcoin UTXO, impulsando un ecosistema único

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

El modelo Bitcoin UTXO, impulsando un ecosistema único

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps