Posterior a observar en diversos repositorios y páginas webs de internet al final encontramos la solución que te compartiremos más adelante.
Solución:
React en sí mismo no es particularmente obstinado sobre la arquitectura de software. Es una biblioteca que facilita el paradigma de componentes reutilizables junto con pautas para administrar cosas como el estado y el intercambio de datos (accesorios). En algún momento, Facebook describió esto como the V in MVC pero desde entonces me he alejado de ese marketing para llamarlo de manera más abstracta A JavaScript library for building user interfaces.
Por supuesto, las herramientas típicas asociadas con las aplicaciones React se prestan a una especie de arquitectura cuando se usan juntas.
Un par de posibles formas de pensar en ello:
Las aplicaciones simples de React pueden ser simplemente “VVM” o “VC”
MVC es probablemente el más conocido de los dos en el mundo del desarrollo. los key La diferencia conceptual entre un controlador (C) y un modelo de vista (VM) podría resumirse en: un controlador puede tener muchas responsabilidades diversas, como escuchar eventos y enrutarlos en la dirección correcta. Es el pegamento que facilita la funcionalidad de toda una aplicación. A ver modelopor otro lado, es simplemente responsable de pegar el estado actual de los datos al modelo.
Entonces, el uso original de Facebook de “V en MVC” probablemente podría haber sido “V en MVVM”: el término controlador tiene más sentido en el mundo del desarrollo de back-end.
Una aplicación barebones React, sin Redux, que extrae datos directamente a los componentes (por ejemplo, fetch‘pecado componentDidMount o aprovechando GraphQL) con disputas de datos limitadas de cualquier tipo podría llamarse un modelo “VVM” simple.
Ver modelo (VM): código relacionado con componentes que administra el estado simple, pasa datos directamente a View, potencialmente pasa datos directamente desde View
Ver (V): Cómo se ven las imágenes (JSX, CSS)
Agregue algo de complejidad, y podría llamarlo “MVVM”/”MVC”
Si arrojas Redux, redux-saga, o incluso comenzar a hacer cosas locas con el estado simple del componente React, está introduciendo operaciones de modelo. Hay al menos dos cosas en este Modelo (M) puede representar:
- Lógica comercial real para su aplicación
- Almacenamiento y gestión de comportamientos complejos en su cliente
La lógica comercial a veces no es deseable en la práctica: por ejemplo, si tiene control sobre el servidor, podría valer la pena mantener toda su lógica comercial en un solo lugar (en el servidor) y solo alimentar la interfaz de usuario con lo que necesita para interactuar con el usuario. Pero si tiene puntos finales REST limitados y necesita hacer algunas disputas (por ejemplo, en sus sagas o dentro de los componentes), esa será la lógica comercial.
Es probable que se administre el comportamiento del cliente, especialmente en aplicaciones complejas en las que podría estar haciendo cosas como mostrar diferentes cosas al usuario en función de su sesión (por ejemplo, es un usuario no registrado frente a un usuario frente a un administrador). Probablemente esté haciendo esto en cualquier interacción de la tienda redux que esté contenida para usar solo por el cliente.
Descargo de responsabilidad: discutir MVC, MVVM, etc. es probable que conduzca a muchas opiniones diferentes de exactamente lo que ellos quieren decir [1]. Arriba, traté de establecer paralelismos entre los patrones comunes que he visto y cómo encajan en MVC/MVVM, pero hay muchas formas diferentes de abordarlo o formas más granulares de pensar en ello. No me obsesionaría demasiado con ponerle una etiqueta siempre que su sistema sea fácil de entender: modular, SECO, abstracto, etc. en niveles que tengan sentido para su caso de uso y escala de desarrollo.
[1] Discutido en un poco más de extensión en respuestas y comentarios a esta pregunta.