Context:
The development team is currently working on a sophisticated REST-based web application using Angular and the @ngrx library for managing state effectively.
In order to represent entities retrieved from the server, such as accounts and users, we have decided to create TypeScript classes. This approach offers benefits like reducing dependency on API changes and encapsulating key functionalities like creating a `fullName` property by concatenating first and last names.
One challenge we are facing is determining the optimal timing for initializing these model entities within our application. Should we instantiate them early on, when fetching data in a service, or postpone it until they are used in specific components?
this.apiService.fetch(AccountService.URL)
.map(accounts => accounts.map((a: AccountResponse) => new Account(a)));
Although the current method of initializing and storing Account objects works, adhering to ngrx/redux best practices raises concerns about maintaining only plain objects in the store for serialization purposes.
Following this advice would require delaying the initialization of Account objects until much later in the application flow, potentially at the component level rather than during data retrieval.
This approach seems counterintuitive as it involves passing raw account response objects throughout the application, diminishing the purpose of encapsulating them within model objects.
Comparing our structure with the simplicity of the @ngrx/example book app, which does not utilize model objects for server responses, adds another layer of complexity to our decision-making process.
Inquiries:
Aside from serialization challenges, what drawbacks might arise from storing initialized classes in the state?
If plain objects are preferred in the store, where do you recommend initializing model classes within the data flow of the application?