reactjs - example - flux varias instancias de la tienda
react flux github (1)
La manera Flux es crear tiendas singleton. No son modelos ya que estamos acostumbrados a pensar en modelos en un patrón MVC estilo ORM. Las tiendas se instancian solo en el momento de la inicialización de la aplicación. Administran un "dominio" de lógica y datos.
Estas tiendas de singleton registran una devolución de llamada con el despachador. La devolución de llamada es la única forma en que los datos ingresan a las tiendas. Las tiendas también ofrecen métodos getter como API pública, la única forma en que se obtienen los datos. No hay setters Las tiendas son un universo propio, controlan por completo sus datos y su comportamiento.
En su caso, parece que los dominios lógicos son Atleta y Entrenamiento, así que crearía una Tienda de Atletas y una Tienda de Entrenamiento, y mantendría colecciones de esas dos cosas dentro de sus respectivas tiendas. Me imagino que tendrás getters como getWorkoutsByAthleteID() , por ejemplo.
En una aplicación de flujo donde los datos se dividen en depósitos por identificación del propietario, ¿deberíamos usar una tienda que internamente separa los datos en depósitos, o una instancia de tienda por cubo?
Por ejemplo, tenemos un usuario de la aplicación que es un entrenador para múltiples atletas. Cada atleta entrenado tiene cero o más entrenamientos, y el entrenador puede ver uno o más entrenamientos de atletas al mismo tiempo.
Podríamos tener una tienda de entrenamiento para todos los atletas; la tienda debe asegurarse de que todos los datos estén separados en categorías de atletas, y cada método de tienda requiere un parámetro de atleta.
O bien, podríamos tener una instancia de tienda por ID de atleta. Esto simplifica la lógica de tienda y las firmas de métodos, pero luego tenemos que administrar más instancias de tienda.
¿Alguien tiene alguna experiencia con este enfoque? ¿Alguna ventaja o desventaja de hacerlo de una manera u otra? O, ¿de qué manera es "el camino del flujo", y por qué?