Why You Should Use Types Instead
Join our Vibrant Discord Community for exclusive information and insightful discussions
Types and In...
For further actions, you may consider blocking this person and/or reporting abuse
IMO the described criteria are not enough to say “stop using” 😅 I’d say, use interfaces for object-oriented code and types for more functional codebases. And as usual, consistency importance prevails over specific choice.
My thoughts though 😃
STOP posting STOP posts if you are not aware of the topics you're ranting about. Interfaces and types have clear distinction on use cases and both are essential for TS.
💯
NO!
Interfaces are interfaces and type definitions are type definitions. You should probably dig into the history of both before starting another "best practices" scam.
Alternatively one could stick to what TypeScript team recommends. Always type over interface seems like religious fundamentalism 💁
"For the most part, you can choose based on personal preference, and TypeScript will tell you if it needs something to be the other kind of declaration. If you would like a heuristic, use interface until you need to use features from type."
STOP using CLICKBAIT titles
The argument that you should stop using interfaces because of declaration merging is completely bogus, since use of this typescript feature is extremely rare, and it's doubtful more than a few typescript programmers even know about it.
At Google we're required to use interfaces instead of types. If you do use a type, it gets flagged by the TS linter and the presubmit check would fail.
In practice types and interfaces are complimentary language features, and sometimes for advanced type manipulation, these features must be used in combination.
How do you handle generics that produce mapped types with mere interface if it's linter flagged? Do you just write new interface instead? 🤔
The rule at Google is, don't use a type if you can use an interface. Of course this doesn't rule out all use of type-style declarations. Really, it just boils down to this:
type T = {n: number};
vs
interface I {n: number}
The latter is allowed, the former is not.
Subject: Apology for Posting Incomplete Blog Content
Dear Esteemed Blog Readers,
I hope this message finds you well. I am writing to extend my sincerest apologies for the recent oversight regarding the incomplete documentation in the blog post I shared with you all. It was an error on my part to neglect thorough verification before posting, and I deeply regret any inconvenience or confusion it may have caused.
I understand the importance of providing accurate and comprehensive information to our readers, and I take full responsibility for falling short of this standard. Please know that this oversight does not reflect the values or commitment of our blog team.
I want to assure you that I am taking immediate steps to rectify this situation. I will diligently review the complete documentation and replace the incomplete content with accurate and detailed information within the next few days.
Your trust and engagement are of utmost importance to me, and I am dedicated to ensuring that our blog maintains the highest quality standards. Your understanding and patience during this time are greatly appreciated.
If you have any further questions or concerns, please do not hesitate to reach out to me directly. Thank you for your continued support and readership.
Warm regards,
Afzal Imdad
Imagine being a "Person" but also being "Work"...
You'll soon be a "Person" implementing "Unemployed" if your employer sees this post!
Correction: According to my wife, I am indeed, a piece of "Work"...
I found out that the best for our team is to use types for data and interfaces for function parameters and vue component props.. This way we achieve both dependency inversion and interface segregation in our vue/ts cosebase.
eg.:
Function doesn’t and shouldn’t need to know anything about age.
The difference for us is simple. Type is always complete, interface might and probably is only partial.
That last line isn’t necessarily true. Types and interfaces both have support for optional parameters, and obviously at runtime it’s possible for any of the parameters to be undefined.
All you’re doing is inexplicitly creating an extended interface/intersection type.
I might missunderstood you, but my example is exactly the opposite I think.
It’s not about extending ‘Named’ with ‘age’ yet about ommiting ‘age’ from ‘Person’ without any direct dependency on it. So you can use ‘getFullName’ for types ‘Person’, ‘Cat’ or even a ‘Car’ as long as it satisfies ‘Named’ interface 🤔
Sure you can take it the other way and make your data be an intersection type of the component/function types it’s used at, but then there is no segregation..
Am I missing something?
Thanks for the shout-out, but there is a lot that's incorrect in this article.
Classes can implement types.
Interface extensions are significantly faster for tsc to parse than intersections. Types and interfaces are the same, but the way you extend them matters.
There is no 'order of precedence' with declaration merging.
I still agree that types are preferred until you need a feature of interfaces, but I don't think this article has enough fact in it to be used as a reference.
Hello Matt 👏
Please do not write clickbait articles like this when you do not know what you are talking about. It is misleading for junior developers who do not know any better. To anyone reading the comments, ignore this article and instead follow the guidelines laid out by the Typescript team.
Damn you got shut down… and rightly so
Especially, in large code bases, the performance of the interface is better than that of the type in some cases.
github.com/microsoft/TypeScript/wi...
Your exemple : Person extends Job is so wrong and kinda anti clean code...
You don't tell a person has a job by doing that, actually you create Interface Person and Interface Job,
You then create a class to represent a person with a job(extends Person, extends Job)
That's a basic concept of Object oriented programming present in many programming languages.
Tell me you know nothing about TypeScript without telling me you know nothing about TypeScript.
Interfaces are strict, types are not.
I appreciate your efforts, but No thanks!
Tbh I feel like article does a better job of convincing you why you should use interfaces rather than shouldn’t.
The main drawback seems to be declaration merging and while that could cause issues, it’s pretty unlikely to happen in a well managed codebase, so I don’t think the argument is really strong enough.
For my projects I use interfaces primarily for defining object shapes, and then types for creating union types or extending existing types from libraries. They both have valid uses in most Typescript codebases.
Come work with me and I'll force you to use interface by default.
The title sounded clickbait, so i came for the comments to actually learn something.
As both does almost the same, one should stick to what they are comfortable with.
Not informative at all or should I say it's misleading... It didn't give away any useful fact to prove we should not use Interfaces... Click Bait!
Hmm your opinions. But I don’t think it’s a valid reason to say one should stop
You didn't even justify the title of your artical. Please be carefully to select a title and stop wasting time of others.