paint-brush
Cómo estructurar tu aplicación de reacción.por@ven_korolev
68,672 lecturas
68,672 lecturas

Cómo estructurar tu aplicación de reacción.

por Ven Korolyov2018/04/23
Read on Terminal Reader
Read this story w/o Javascript

Demasiado Largo; Para Leer

Cuando trabajas en un equipo grande, siempre es bueno tener una guía de estilo no solo para CSS & JS sino también para estructurar componentes y carpetas. Decidí escribir el mío para mostrar cómo y dónde coloco mis archivos y carpetas. ¡Empecemos!

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Cómo estructurar tu aplicación de reacción.
Ven Korolyov HackerNoon profile picture

Cuando trabajas en un equipo grande, siempre es bueno tener una guía de estilo no solo para CSS y JS, sino también para estructurar componentes y carpetas. Decidí escribir el mío para mostrar cómo y dónde coloco mis archivos y carpetas. ¡Empecemos!

Enlace a la segunda parte.

Siempre divido mis componentes por valor comercial. Yo lo llamo bundle .

Por ejemplo, cada aplicación que he creado tiene un paquete común, que mantiene todos los componentes comunes, como encabezado, pie de página, botón, modal, etc. Si tiene una página de usuario (configuración, fotos, perfil), sería un paquete de usuario. que tendría todos los componentes específicos de un usuario. Es realmente útil tener una estructura como esta porque cada vez que ve una página en un navegador, siempre puede decir dónde necesita ir para encontrar ese componente. También es bueno para los recién llegados que realmente no saben cómo estructura sus componentes. Podrían adivinar qué paquete es. Por ejemplo: /user/22/preview , la página mostraría un componente del paquete de usuario. Es fácil de adivinar.

Cada paquete tiene algunas carpetas:

  1. **actionCreators** tienen acciones redux.

2. **Components** es una carpeta para todos los componentes de un paquete. Cada carpeta en la carpeta de componentes debe nombrarse con una primera letra mayúscula como archivos de todos los componentes. La razón por la que siempre uso la primera letra mayúscula es porque cuando busca un archivo por nombre en su proyecto, siempre puede reconocer los componentes solo por el header del nombre frente al Header , siempre sabe que el segundo es un componente. Antes de seguir leyendo, considere leer este artículo .

Ahora hablemos por qué hay tres archivos en lugar de uno.

Header.js es solo una vista simple. Puede ser un componente sin estado (función) o una clase. Prefiero usar una clase porque las clases funcionan con HMR de fábrica, pero depende de usted. Lo único que debe saber es que la vista es un componente tonto que solo debe representar accesorios y no debe haber lógica comercial allí.

HeaderContainer.js es un componente "inteligente". Este tipo de componentes siempre obtiene datos, prepara datos, obtiene datos de redux-store/ relay , define acciones, inyecta intl o jss. Es un buen lugar para componer componentes de orden superior . Por lo general, no importa reaccionar dentro de los componentes inteligentes porque no debe representar nada allí. Así es como debería verse:

index.js solo vuelve a exportar componentes. Si importa sus componentes en algún lugar de su aplicación, lo haría como este import Header from 'bundles/common/components/Header/Header.js' . Para evitar el doble Header/Header.js , podemos volver a exportar nuestro componente Header dentro de index.js. También es bueno tenerlo aquí porque puede tener dos contenedores y solo una vista, por ejemplo: CreateUserFormContainer.js UpdateUserFormContainer.js y solo una vista UserForm.js . Y, por supuesto, tiene dos rutas diferentes: update-user y create-user .

Ahora podemos importar nuestros componentes como import { Header, HeaderContainer } from 'bundles/common/components/Header';

3. **reducers** es una carpeta para todos los reductores de un paquete. El reductor para intl.js se vería así:

4. La carpeta **routes** guarda todas las rutas del paquete actual. Puede tener algunos archivos de rutas para el mismo paquete. Para un paquete común, no es normal tener ninguna ruta porque es un paquete común, pero digamos que tenemos una ruta que muestra nuestro encabezado: /header .

Recojo todas las rutas en el archivo de cada ruta y las exporto como una matriz. Más tarde, en mi punto de entrada de la aplicación, importo todas las rutas, las fusiono en una matriz y renderizo dentro del Router .

Conclusión. Lo único que importa es qué tan cómodos se sientan usted y su equipo trabajando juntos. La guía de estilo es solo una convención que usted y su equipo definen. Espero que hayas disfrutado este artículo. Por favor, dale me gusta y comparte si te gusta. Paz.

Enlace a la segunda parte .