Where to initialise model objects within a redux / ngrx application architecture

Question

Background:

Team is building a large REST-based web application using Angular and the @ngrx library for state management.

We wish to model entities from the server as TypeScript classes. These may be: accounts, users etc

This achieves:

• Loose coupling to the API; if the response changes, only the model must change
• Encapsulating basic functionality e.g. string concatenation of first and last name to make fullName

The uncertainty lies in when, during the application's timeline, to initialise the model, calling: new Account(accountResponse).

Conventional logic suggests to do this as early as possible, in a service along side the logic to retrieve the accounts (be it from a cache, server response, etc).

this.apiService.fetch(AccountService.URL)
      .map(accounts => accounts.map((a: AccountResponse) => new Account(a)));

This method is invoked by an ngrx effect, then following a successful response, the Account objects are added to the store by the reducer.

This works, however... ngrx / redux "best practice" states only plain objects and primitives should be kept in the store, for ease of serialisation among other reasons.

To adhere to this advice, initialising the Account object must happen much further down the line. Either in individual components, in a state selector, or generally wherever an account is used.

This doesn't make sense to me, as the raw account response objects are being passed around the application, somewhat defeating the point of wrapping them in a model in the first place.

The application is structurally similar to @ngrx/example book app which, given its simplicity, does not wrap the server responses in model objects.

---

Questions:

• What are the detrimental effects of keeping initialised classes in the store (besides serialisability)?

• If only plain objects are to be kept in the store, where in the flow of data through the app are model classes best initialised?

Answer 1

The easiest way to work with ngrx is to see it like a database, not just a javascript shared object cache. You would not store javascript helpers in the database, same for ngrx.

You can either stop using model functions and instead use utility methods when needed, or you can wrap the selector results using an observable operator. Something like state.pipe(select(mySelector), myWrapFunction) though you will end up re-creating your wrapper every time.

You might want to look at the viewmodel design pattern (e.g. [MVVM] (https://en.m.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel)) to see approaches similar to what you are trying to do.