Fondo:
El equipo está creando una gran aplicación web basada en REST utilizando Angular y la biblioteca @ngrx para la gestión de estado.
Deseamos modelar entidades del servidor como clases de TypeScript. Estos pueden ser: cuentas, usuarios, etc.
Esto logra:
fullName La incertidumbre radica en cuándo, durante la línea de tiempo de la aplicación, inicializar el modelo, llamando: new Account(accountResponse) .
La lógica convencional sugiere hacer esto lo antes posible, en un servicio junto con la lógica para recuperar las cuentas (ya sea desde un caché, respuesta del servidor, etc.).
this.apiService.fetch(AccountService.URL) .map(accounts => accounts.map((a: AccountResponse) => new Account(a)));Este método es invocado por un efecto ngrx, luego, después de una respuesta exitosa, el reductor agrega los objetos Cuenta a la tienda.
Sin embargo, esto funciona... La " mejor práctica " de ngrx / redux establece que solo los objetos simples y primitivos deben mantenerse en la tienda, para facilitar la serialización, entre otras razones.
Para cumplir con este consejo, la inicialización del objeto Cuenta debe ocurrir mucho más adelante. Ya sea en componentes individuales, en un selector de estado o, en general, donde se use una cuenta.
Esto no tiene sentido para mí, ya que los objetos de respuesta de la cuenta sin procesar se pasan por la aplicación, lo que anula un poco el punto de envolverlos en un modelo en primer lugar.
La aplicación es estructuralmente similar a @ngrx/example book app que, dada su simplicidad, no envuelve las respuestas del servidor en objetos modelo.
Preguntas:
¿Cuáles son los efectos perjudiciales de mantener las clases inicializadas en la tienda (además de la serialización)?
Si solo se van a guardar objetos simples en la tienda, ¿en qué parte del flujo de datos a través de la aplicación se inicializan mejor class modelo?
La forma más fácil de trabajar con ngrx es verlo como una base de datos, no solo como un caché de objetos compartidos de JavaScript. No almacenaría ayudantes de javascript en la base de datos, lo mismo para ngrx.
Puede dejar de usar funciones de modelo y, en su lugar, usar métodos de utilidad cuando sea necesario, o puede envolver los resultados del selector usando un operador observable. Algo así como state.pipe(select(mySelector), myWrapFunction) aunque terminará recreando su contenedor cada vez.
Es posible que desee ver el patrón de diseño del modelo de vista (por ejemplo, [MVVM] ( https://en.m.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel )) para ver enfoques similares a lo que estás tratando de hacer.
@kyranjamie Estoy tratando de entender cómo hacerlo de la manera más práctica. ¿Te entendí bien? Almacenas un objeto simple en un estado. Cuando un componente necesita el objeto del estado, utiliza un servicio, por ejemplo: HomeService : para obtener el objeto HomeModel en lugar de un objeto simple
@Injectable({ providedIn: 'root' }) export class HomeService { constructor() { } public getSelectedHome(homeObject: HomeJSON) { return Object.assign(new HomeModel(), homeObject); } }Un componente necesita suscribirse al estado. Está suscrito a un cambio en el estado, pero en lugar de usar directamente el objeto simple de estado, usa HomeService para convertir el objeto simple en un objeto de clase (HomeModel).
ngOnInit() { this.store.pipe(select(getSelectedHome)).subscribe( home => { this.home = this.homeService.getSelectedHome(home); } ); }¿Es así como lo haces?