8

I have a login/registration module and I want to write a model for them.

I would use interfaces, but I need to have one predefined value.

And I was wondering - should I put the predefined out as a constant (it won't be changed, altered) and use interfaces. Or write it as classes (as currently)

Currently, I wrote two separate classes - registration.model.ts, login.model.ts, could I be able to abstract to use only one model? (example: user.model.ts)

Some examples:

export class LoginUser { constructor( private email, private password, // I need to have it, backend expects it to be sent private connection = 'Username-Password-Authentication' ) { } } export class RegistrateUser { constructor( public name: string, public lastName: string, public email: string, public password: string, // I need to have it, backend expects it to be sent private connection = 'Username-Password-Authentication' ) { } }
Improve this question
3
  • 1
    Hey @Aravind, was wondering what you meant by that comment? Commented Aug 7, 2017 at 5:36
  • 1
    @N15M0_jk not to speak for him, but I think it is a useful comment. TypeScript is JavaScript and JavaScript is very different from C# and Java. Using classes for plain old data is an anti-pattern in TS/JS. It creates complexity and exposes rough edges of the language where there is no need to do so. Commented Aug 7, 2017 at 17:27
  • 1
    @AluanHaddad Thanks for the reply man, was randomly browsing around and happened to come across the comment and was just curious. IMO - there's quite a lot of programming constructs that are reflected in Typescript (Angular seems to shy away from them at times - as you say, some are anti-patterns). But thanks for the response Commented Aug 8, 2017 at 6:25

2 Answers 2

Reset to default
4

just came across your question & was investigating the same thing.

With reference to the Angular 2 Style docs here, the 'guideline' is to NOT implement an interface on the premise that a class alone can:

  • Act as an interface (if you use the implements keyword instead of the extends keyword)
  • Be smaller than a class-implementing-interface

As a rule of thumb:

Angular Guidelines > Typescript Guidelines (in the case of Angular 2 projects).

Hope this helps you out! :)

Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

I strongly disagree. The Angular guidelines are wrong on this point, emphatically wrong. Consider export class UserService {get(): Observable<User> {return this.http.get(...).map(r => r.json());}} consumed as export class UserComponent {ngOnInit() {this.service.get().subscribe(user => { if (user instanceof User){ /*never executed ever!*/ }});})}}
Keep in mind that they are guidelines/style guides, for the most part they're correct to follow, it's likely there will be instances where a case like the above won't be accounted for. What you're probably looking to use is an abstract class instead which abides by Angular's style guides of not implementing an interface
It is interesting that Googles Angular team decided to go with Typescript, for a ton of good reasons, yet their guidelines do NOT match up with Typescript guides. Interfaces and classes are typescripts are not the same as in C#. bonus points. .. One is at runtime other is at compile time! Angular team says to just use classes... while Microsoft gurus of strongly typed code coupled with them becoming google dev experts tend to encourage interfaces. Overall it is situational
@TomStickel thats probably because of Angulars DI
@ConquerorsHaki quite so, and that is precisely why I object to this approach. In TS, a class simultaneously introduces a type and a value (constructor) that instantiates values of that type but, they can be used independently. Thus, and as you quite correctly point out, any use of the type without a corresponding use of new operator is spurious. What I am objecting to is that declaring a class to introduce such types is bad practice because it allows such spurious use, i.e. without new.
|
1

I would definitely use interfaces. It is a simple approach and follows the TypeScript recommendations for working with JSON.

The property in question, 

private connection = 'Username-Password-Authentication';

can well be added by the service that performs the request.

This will also reduce code duplication because you can use a generic function or service to create this request object.

For example:

export default function withRequiredAuthProps<T>(model: T) { return {...model, connection: 'Username-Password-Authentication'}; }

Then your Http service that sends the model back to the service can use a type constraint to verify that the property has been added before making the request

For example:

export default class MyHttpClient { post<T extends {connection: 'Username-Password-Authentication'}>(url: string, body: T) { //... } }

These are just meant as examples but they are based on code that is minimal, and that works.

Improve this answer

1 Comment

@ConquerorsHaki quite so, and it is wrong. It is quite bad code. JSON.parse does not instantiate classes it creates simple objects with no heritage. By using classes to describe their shape, as their interface, completely erroneous code e.g. instanceof is allowed. The angular style guide is full of awful code at any rate. For example, it is full of examples that pass unbound member functions as callbacks. You must admit at least that this latter is indefensible

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.