javascript - reducer - redux fetch

Estructura de proyecto fractal con reacción y redux-pros/contr (2)

El único inconveniente con el que puedo hablar es que no puedo ver de at a glance todas las rutas disponibles y sus respectivos componentes, esto se puede mitigar haciendo algunos comentarios descriptivos, pero aumenta la complejidad de la configuración de su ruta. También trataría de mantener las carpetas de anidamiento al mínimo, ya que existe una carga cognitiva asociada con los niveles de anidamiento correctos en sus declaraciones de importación, es decir, ../../../../../ estos pueden salirse de control si Tienes muchas rutas anidadas.

Me gustaría saber cuáles son los pros y los contras de usar una Estructura Fractal en un proyecto React + Redux y me preguntaba si alguien tiene alguna experiencia con este enfoque o si hay errores que no son visibles de forma inmediata en los documentos.

(Estructura fractal) También conocida como: Aplicaciones independientes, Jerarquía de rutas recursivas, Proveedores, etc.

Contexto: estoy mirando react-redux-starter-kit y sugiere usar una estructura fractal para organizar las carpetas. Si entendí bien, este enfoque requiere organizar las carpetas del proyecto por característica y anidar la ruta de forma recursiva.

Entonces, si tengo un "evento" de recursos donde

/events lista todos los eventos
/events/new muestra un formulario para insertar un nuevo evento
/events/1/details muestra los detalles sobre el evento con id 1

A partir de la plantilla, tengo que agregar la nueva carpeta de ruta como:

├── src # Application source code │ ├── main.js # Application bootstrap and rendering │ ├── components # Reusable Presentational Components │ ├── containers # Reusable Container Components │ ├── layouts # Components that dictate major page structure │ ├── static # Static assets (not imported anywhere in source code) │ ├── styles # Application-wide styles (generally settings) │ ├── store # Redux-specific pieces │ └── routes # Main route definitions and async split points │ ├── index.js # Bootstrap main application routes with store │ ├── Root.js # Wrapper component for context-aware providers ~ ~ │ ├── Events # Fractal route │ │ ├── index.js # Route definitions and async split points │ │ ├── components # Presentational React Components │ │ ├── container # Connect components to actions and store │ │ ├── modules # Collections of reducers/constants/actions or single DUCK module │ │ └── routes # Fractal sub-routes (** optional) <------------- │ │ │ │ │ └── New │ │ │ ├── index.js # Route definitions and async split points │ │ │ ├── assets # Assets required to render components │ │ │ ├── components # Presentational React Components │ │ │ ├── container # Connect components to actions and store │ │ │ ├── modules # Collections of reducers/constants/actions or single DUCK module │ │ │ └── routes # Fractal sub-routes (** optional) <------------- │ │ │ │ │ └── Details │ │ ├── index.js # Route definitions and async split points │ │ ├── assets # Assets required to render components │ │ ├── components # Presentational React Components │ │ ├── container # Connect components to actions and store │ │ ├── modules # Collections of reducers/constants/actions or single DUCK module │ │ └── routes # Fractal sub-routes (** optional) <------------- ~ ~ │ └── NotFound # Capture unknown routes in component ~

Con New carpeta New y Details anidada en la carpeta Event raíz.

Los documentos destacan estos principales pros:

Se adapta mejor que una estructura de directorios plana, con carpetas para componentes, contenedores, etc.
Las rutas se pueden agrupar en "trozos" utilizando el algoritmo de fusión y fusión de código de webpack
Dado que la lógica es autónoma, las rutas se pueden dividir fácilmente en repositorios separados y hacer referencia al complemento DLL de webpack para un desarrollo y escalabilidad flexibles y de alto rendimiento.

El único inconveniente o inconveniente que he encontrado con una estructura similar es que si / cuando las cosas comienzan a usarse fuera de su jerarquía, entonces tiene que usar muchos ../../.. en sus importaciones.

Por ejemplo, supongamos que obtiene el requisito de que en su ruta de StartPage debe mostrar los detalles del evento más reciente.

así que ahora se ve como:

routes ├─Events │ ├─New │ ├─Details ├─StartPage ├─ components // here somewhere you import ../../Events/Details

No es el fin del mundo, pero su buena jerarquía ya no es tan estrictamente jerárquica.