Typescript and Angular 6 - Mapping Service Results to Data Transfer Objects

Question

I think I am just look for a bit of code review advice. It might possibly be a methodology question?

Essentially when I am pulling data (usually from a REST request), I generate a service, then inject HTTPclient of Angular common so I can use a simple GET to grab the data. Like below:

interface ReportContact{
  Email: string;
  Name: string;
  ReportName:string;
  ReportType:string;
  ReportFunction:string;
}

@Injectable({
  providedIn: 'root'
})


export class ReportingContactService {

  private readonly url = environment.url; 
  private _http:HttpClient;
  constructor(http:HttpClient) {
    //DI 
    this._http=http;
  }

    getReportContacts():Observable<ReportContact[]>{
    return this._http.get<ReportContact[]>(this.url);
  }
}

This is generally my go to when I am making a simple service. I then usually use this service in my component like below:

export class ReportingContactComponent implements OnInit {

  _service:ReportingContactService;
  data:ReportingContact[];

  constructor(service:ReportingContactService) {
    //DI service
    this._service = service;
   }

  ngOnInit() {
    this._service.getReportContacts().subscribe(
      data=> {
            for(var element of data){

            }
    });
  }

}

Now, where I was hoping for some review and pointers on is, should I now be mapping the return of that service to a class that I create as a model? I am used to the mindset of separating data type objects from the objects used in the rest of the application. So essentially in that for loop (of the component.ts), I would map to these new objects which look like below:

export class ReportingContact{
    Email: string;
    Name: string;
    ReportName:string;
    Type:string;
    Function:string;
}

Am I wasting my time and is this generally not the "norm"? Again, I just have always come from the mindset of separating, but the Angular framework (or maybe just TS and JS) has introduced new ways of thinking for me, so I like to be keeping to the generally accepted standards.

Answer 1

The short answer for this specific case would be: no there is no reason to map the (interface) result to a class. Since your class doesn't have any functions, doesn't do anything specific in it's constructor and only exposes the exact same properties the interface does, there is no added value in doing so.

There are however a few things you should consider:

1. bundle size

When compiled to javascript, interfaces will not generate any code while each class will result into a javascript prototype. Therefore a lot of Typescript classes will end up in a lot of javascript code (useless code if you end up only using them like interfaces)

Consider using the typescript playground to see what code typescript compiles to

Compiled interface and class

2. how javascript uses your types

While using interfaces/classes allows you to catch compile time code-errors, it does not guarantee you won't have any at runtime. For example if your http result doesn't fully comply with your interface ( e.g. the email property is missing) javascript won't care about that, resulting in an undefined reference error when you try to do something with it.

You could use your class contructor to make sure all properties are initiated correctly or provide a default value (example) Doing so will prevent these errors at runtime or enable you to handle them before they become an actual issue.

3. how you use your classes

In frontend (Angular) applications interfaces often times suffice as they are only meant as vessels to present data to your user. As your applications grow however, you often times find yourself in need of more and more client-side bussiness-logic. In these cases classes can be key to a domain driven client side architecture