español - ngrx angular 6 tutorial

Transformación de datos en Clase vs Reductor(ngrx/redux)

Question

Usando ngrx / redux, y siguiendo la aplicación de ejemplo ngrx lo más cerca posible. Ahora estoy haciendo esto en alguna parte de la aplicación:

get totalItems (): number {
   return sumBy(this._data.items, ''metadata.value'');
}

Donde _data es la información asíncrona sin procesar de un servidor remoto, y es parte de algunos datos de un User .

Ahora tengo algunas opciones:

1. Crea un User clase

constructor (public _data: UserResponse) {}

Y tiene algunos métodos como:

get name (): string {
  return this._data.name;
}

get address (): string {
  return this._data.address;
}

Y, además, elementos como los totalItems antes mencionados y otros accesos directos para obtener un resultado diferente al de los datos sin procesar. Lo que no me gusta es la repetición de las propiedades y dónde usar esta clase;

• ¿Utilizo la clase de User en el api-service y devuelvo los datos transformados al módulo @Effect , que a su vez activará las acciones de SUCCESS o FAILED ?
• ¿Lo pongo en el módulo @Effect , justo antes de que se @Effect la acción?
  • ¿Uso extends o implements en el componente angular?

Otra cosa es que aplicamos los datos transformados en la propiedad de la payload , lo que dificultaría la depuración de los datos remotos sin procesar.

2. Otra opción sería transformar estos datos dentro del reducer :

El reductor actual:

case ActionTypes.FETCH_USERS_SUCCESS:
   return {
     ...state,
     users: action.payload
   };

Lo que podría hacer:

case ActionTypes.FETCH_USERS_SUCCESS:
   return {
     ...state,
     users: action.payload.map((user) => {
        return({ 
          ...user, 
           totalItems: sumBy(user.items, ''metadata.value'' });
     })
   };

¿Es esto una práctica anti patrón o mala? Porque veo que .filter se usa en ejemplos todo el tiempo, y no veo que sea impuro, entonces, ¿cuáles serían los argumentos a favor / en contra de hacerlo en el reductor? De esta forma podría eliminar la necesidad de una clase de User y cargar todos los datos necesarios en un componente.

Y, evitando que los reductores se llenen de mucha lógica, quizás haga un reductor separado para esto, que "escuche" las mismas acciones.

Opción 3:

Ponlo en un selector:

export const selectUsers = createSelector(selectUsersState, (state: Userstate) => state.payload.map((a: UsersResponse) => new User(a)))

Leyendo esta respuesta por @dan_abramov: ¿Cómo poner métodos en los objetos en el estado de Redux? me implica que la segunda opción tiene más sentido para esto, como él dice:

"En Redux, realmente no tiene modelos personalizados. Su estado debe ser objetos simples (o registros inmutables). No se espera que tengan ningún método personalizado".