News for hackers. Stuff that matters.
Re:Typescript: class vs. interface by Matthias247 on Tuesday February 27, 2018 @11:21AM (#16474861)
My personal rule of thumb:

- If I'm dealing with pure data (of varying sources) I use interfaces

- If I'm modelling something which has an identity and state (and probably attached methods to modify the state) I'm using a class.

Wrote a bit more about it here: https://stackoverflow.com/questions/40591413/interface-and-c...

Re:Typescript: class vs. interface by Parsyval on Tuesday February 27, 2018 @11:27AM (#16474947)
"interfaces don't have a runtime representation" I was looking for a good way to say that while writing the article, this is a very good way ! Thanks Also I like that you think about the use of instanceof, I didn't really think of that, but some devs use this condition intensively.
Re:Typescript: class vs. interface by electrotype on Tuesday February 27, 2018 @11:51AM (#16475240)
I agree. Using classes for entities allows you to use libraries such as https://github.com/typestack/class-transformer

And allows you to use "instanceof". User defined type guards for interfaces are hackish at best.

Re:Typescript: class vs. interface by Legogris on Wednesday February 28, 2018 @02:20AM (#16481320)
"instaceof" is something I would advise against for any code that might be called from another module.

If you have different modules requiring that same module and they for whatever reason (webpack behavior, node not deduping properly, npm link, different versions, etc), that instanceof will fail and the caller will be left scratching their head as to why their object fails the check.

In JavaScript (and by extension TypeScript), you are best left to duck-typing for run-time checks.

Re:Typescript: class vs. interface by leshow on Tuesday February 27, 2018 @01:02PM (#16476080)
Why don't you use a type alias instead of an interface for pure data?