I Cannot Believe TypeScript Recommends You Do This!
Vložit
- čas přidán 22. 05. 2024
- TypeScript Simplified: courses.webdevsimplified.com/...
The TypeScript documentation is definitely not as good as it could be, but one thing that blows my mind is their recommendation of using interfaces over types. Types are more powerful in nearly every way which is why I love them and in this video I explain all the differences between types and interfaces and why you should probably be using types.
📚 Materials/References:
TypeScript Simplified: courses.webdevsimplified.com/...
🌎 Find Me Here:
My Blog: blog.webdevsimplified.com
My Courses: courses.webdevsimplified.com
Patreon: / webdevsimplified
Twitter: / devsimplified
Discord: / discord
GitHub: github.com/WebDevSimplified
CodePen: codepen.io/WebDevSimplified
⏱️ Timestamps:
00:00 - Introduction
00:40 - Which is best
01:20 - Creating types/interfaces
02:10 - Reason #1
03:26 - Reason #2
05:14 - Interface myth
05:48 - Interface benefit #1
#TypeVsInterface #WDS #TypeScript
Hey Kyle! Loving all the TS content coming out of your channel.
Wanted to drop by with a clarification that probably ALSO needs to be on my types vs interfaces video.
When we're talking about performance with types vs interfaces, the difference is negligible when just declaring basic object types. The real performance gap is between intersections (&) and 'extends'. There is a pretty big gulf in performance between them - intersections are bloody hard for TS to resolve and so take a lot longer. Using extends is much easier and also comes with some correctness guarantees. I've seen a lot of folks in the community moving towards interfaces for that reason - interface extends really can speed up your TS codebase by a large factor.
I also neglected to mention this in my types vs interface video, it's a nasty little nuance that isn't clear on first look.
Love your stuff as always!
I wanna kiss your forehead every waking hour 💋
But extends and intersections serve different purposes. I think extends and union are more similar. Interfaces have no ability that I'm aware of for intersections.
I think I understand what you mean now. I was thinking of intersections on unions, and they work completely differently on unions. Intersections on object types are indeed basically the same as extends on interfaces. It's a little surprising that it would be a lot slower for types, but I guess that makes sense when they're capable of so much more.
Speed up transpiling or runtime?
@@kevinclark1783 Transpiling
To be very honest, this debate is completely unnecessary for me, I have used both, but I never found i have a huge problem just because i use interface, not type and vice versa.
Kyle is great. But most CZcamsrs need new content so yeah many times it’s not a big deal.
It's not a big deal but Consistency is good. Makes the code more readable
I find for exemple that the first reason is not really a problem
But you actually supported they advice, because they say you should use types if you need it’s features. And this is what you showed.
Personally I dont see an issue with mixing them up, we do it all the time
agreed, problem with coding youtubers is that they've never worked in the last few years so they just keep spouting nonsense that no one cares about at work.
1. Types intersection is NOT equal to extending interfaces.
Intersect two types like { name: string } & { name: number } an see what happens.
And happens "{ name: never }" instead of an error. Good luck tracking that in a project with more or less big types structure.
2. Types for some reason have an implicit index signature, which will bite you when you less expect it. When you denied to pass "just an object" to your func, for example, because that object "does not have an index signature", suddenly.
Overall, this whole video sounds like "oh, I cannot use same syntax for two totally different tools with different tasks, so I'll use just one of them". What kind of arguing is that? Please don't do this.
Fax
When this guy uploads a video, I always go to the comments to see the real LPT. I should thank him for that at least.
1. To play devil's advocate, that isn't difficult to track in a large project at all. It becomes obvious as soon as you start actually using the `never` type, because then you'll see a type error, and it's no harder to fix than for interfaces (e.g. by removing or `Omit`ting the conflicting key).
2. There's a trade-off here; interfaces' explicit index signatures can also lead to unsafety. I recently tried to make a `Serializable` utility type, but my serializable interfaces weren't assigable to it because TS knows they can be extended to become unserializable (even though I know mine won't be). So I had to make my interfaces extend `interface SerializableRecord { [key: string | number]: Serializable | undefined }`. In a way, this is safer now that nobody can extend my interfaces to be unserializable. But in another way, it's less safe now that I can set nonexistent fields on my interfaces (since they're `Serializable | undefined`) without seeing a TS error, and I may not find out until runtime in production. And not only that, but with the explicit index signature, my classes could no longer implement my interfaces, since classes can't let any string index them. So I was practically forced to use types instead of interfaces.
Still learning here, are you saying interfaces can solve that particular issue? Such as:
interface one {name: string}
interface two extends one {name: number}
that throws an error right? So is the benefit here that with interfaces, this gives an error and we realize sooner so we don't get the issue of "{ name: never }"
@@Nelsonm97 That is what they were saying in their first point, yes. (And I don't think this is an important point in favor of interfaces, as I explained in my previous comment.)
Having come from "classical" OO languages, I tend to use Types for when a thing "IS-A" other_thing. Interfaces are for when a thing "BEHAVES-LIKE" other thing. In other words, use the 2 styles for what your things are, or they do, not based on the capabilities necessarily. Sometimes you have to, of course.
This, exactly. To me, a type defines what an object (or primitive) *is*, while an interface defines *how I can use it*.
Coming from the same background I agree. Best take good old PHP as a reference which also went from un-typed to typed a long long time ago. Types are for data structures and Interfaces are for "local" functions or API's (remote functions) One of the reasons I don't like TS. The authors created their own scheme instead of building on good and accepted practices
U wot m8?
Still makes no sense as you can define behavior in both. Typescript should never have added these as 2 separate items.
The originl intent from OOP world was that interfaces define a "contract" which classes must honor. If you stick with this mindset then things just make more sense. A type can simple be used when you just want to quick structure and shape data.
If having to use types and interfaces together in the same codebase is your biggest problem then you are really having a sweet life
I was feeling the same thing 😅
Imagine opening every file and it uses different things, when importing something you never know if it is an interface or type means you never know if you can use generic types or type utility functions is pretty annoying. I’d rate this higher than a lot of other things in terms of things to agree on in a codebase.
@@SpeakChinglish There is a convention devs use:
Add 'I' to the name of an interface and 'T' to the name of a type.
IUser, TUser.
@@imdanteasynot all developers do that. Seeing such makes me want to puke.
@@SpeakChinglishif you use VS Code or most any other IDE then there is no need. Further most the time I just don’t care. Type?? Interface?? Most the time it doesn’t matter. And it is easy to change one to the other when the need arises.
I'm not convinced. I generally use interfaces for objects, and types for single liners like primitives or utility types. I find they play well together and don't see the issue with mixing them any more than mixing variable types.
When you start to wan to make unions/intersections or Omit, pick and many operations you see yourself using types instead of interfaces. The fact is, if you want consistency then you’ll not use interfaces
@@ChibiBlasphem that's what i mean by utility types. Types work well for single liners.
js, primitives (￢ ￢)
@@ChibiBlasphem I don't know if I agree with the "consistency" argyment. There are times to use interfaces, and times to use types. I feel like that logic would be consistent with not using any classes becuase you prefer functions. They both have their time and need and though you can pretty much do anything in Javascript with a function, there are times that you should just use a class.
@@justinwallace2321 And the only times when you want to use interfaces is for extending it because it's the only thing type aliases doesn't supports it. In every other cases types alias do the job and you get 1. Consistency, 2. Seeing an interface means it's meant to be extended, so clarity.
Another benefit of interfaces over types is that errors are so much easier to read. With types, it just spits out every property name which can get crazy when there are a lot of props, wheras with interfaces it just shows the interface name. I tend to use types more than interfaces, but I am torn on the issue because of the error messaging.
How is showing just the interface name better than showing the exact parts of the type that break better?
@@dhedarkhcustard I don´t think he means it shows you the values of the object. Rather that instead of MyUser it would show { Username: string, Password: string } & { moreStuff: number } & .... Some typescript type declarations get crazy out of hand its not obvious what type you are using when looking at a wall of props like that you don´t even know you are using a type, maybe it´s just inline with the variable and there is no type declaration to be found in your project.
You should definitely read about what interfaces are used for
Interfaces are made to represent objects and DTOs.
Types are made to make few types work as close as primative types, but it can go as complex as you need.
There's nothing complicated about using both types and interfaces in a code base; they each serve a specific purpose. Just like there's nothing complicated about having some variables that are strings and others that are numbers; you use them where they're appropriate, you don't try to homogenized everything to strings. The only issue new developers face is knowing WHEN to use type or interface; telling them to "just use types" does them a huge disservice.
He didn't say only use interfaces, he said use types unless you need the features of interfaces. Misrepresenting someone's argument is not cool.
This is the perfect answer to this video. I feel like this video will just confuse new developers and push them into a bad practice
@@king-manu2758 Ironic response since you're misrepresenting mine! I didn't say he said "only use interfaces", where are you getting that idea? He said in the video "I don't like to mix types and interfaces because it makes the codebase more confusing". I responded to that part saying it isn't confusing if you understand the use cases. Further, making a rule like that is going to mislead a lot of devs new to typescript.
@@king-manu2758 Well maybe his advice is actually not quite good? The main idea and purpose of interface is rather semantic. It is meant to be used as a foundation for describing object interfaces. Any kind of interfaces, actually.
While using both it is harder to confuse the descriptor purpose, because you can tell simply by looking it's definition, if it is a simple type or some object interface.
It's like a convention. For example, we all agreed to have type descriptors starting with the capital letter for the same exact reason - to have a simple distinguishable indicator for descriptor to be variable or type.
Although, some have a tendency to use "I" and "T" to differentiate these two entities and exploit "type" whenever they can.
@@IanZamojc making a rule like that? What rule are you talking about? When he said he doesn't like to mix types and interfaces he wasn't making a rule, he was stating his personal preference. If you're implying he pushed some rule that interfaces should never be used, then you yourself just admitted that's not the case in your previous post. So then what's this rule you're talking about that this guy supposedly made?
I got your point, but i prefer to use Type like a "primitive" and Interface to describe an object.
and... To use OR with interface, you just need to declare 2 or more interfaces and call after, like:
interface A {
a: string
}
interface B {
b: number
}
const obj: A | B ....
🙃
Thank you! I really like this pattern too.
I think that the core point is missing. Type describes the properties of an object, interface describes the behaviors.
Said that, your choice is driven by this difference. Just my two cents
Well… interfaces are meant to be used for objects. You don't actually need to rewrite an interface to be a non-object representation. You can actually use | and & for interfaces:
const response: IErrorResponse | ISuccessResponse = ...
Or using a type to alias them:
type Response = IErrorResponse | ISuccessResponse
const response: Response
----
I only use type for aliases in these cases. But for objects representation, I often prefer using interfaces to mix with classes and implements.
This is how types should be used. to alias two interfaces. As you say, interfaces are for defining objects.
Without having watched the video: I think about it a little bit differently. I generally use types unless I want to 1. Modify/extend a global type outside of my control or 2. If I want to let other code easily extend my interface.
Thanks Kyle! I'm really trying to step up my game at work and I appreciate the typescript content.
For me interfaces should be used when you want to expose a consistent API and make something open to extension but closed to modification where as use types for stuff you return from methods or functions
For example, a database call to fetch a user by ID should return a user *type* but a class responsible for calling the database should implement an *interface*
Yeah that sounds pretty solid.
Simple question, what advantage does it give you other then doing this because it feels right? It doesn't have any advantage at all. Doesn't help you read code faster, doesn't do pretty much anything.
Why though? There's literally nothing in one or the other that offers better suitability for those use cases. Even worse, the caller won't even realize the difference.
@@xromasik Making semantic sense is an advantage in itself. Interfaces make sense when you're going for an object oriented approach since multiple classes can implement multiple interfaces and can be used interchangeably but you cannot make a class implement a type.
However I don't see much use of an interface when you're working with a functional approach, so as I said it's better for functions or methods to use types
@@truevelvett Imagine you want to store some sort of data but you don't want to worry about how it's stored (it might be stored in a JSON file, in memory or in an SQL database)
Well, simply create an interface that defines a bunch of methods like "addUser", "getUser", "deleteUser", etc and based on your use case implement that interface that stores the user object somewhere.
*But now the cool thing is that if in the future you decide to move from let's say storing in a JSON file to storing user details in an SQL server, all you have to do is define a new class that implements the interface that you defined and replace "new UserFileService()" with "new UserSQLService()" without touching the rest of your code*
One thing you don't mention about the benefits of interfaces over types is that interfaces are more OOP while types are more useful to share data around. Interfaces can have functions that are defined to have patterns that are predictable in your code base where the responsibilities are split between your views and your business logic. But, of course, in the front-end, it has less importance as you're mainly just sharing data around your components.
Yep. looks like Kyle doesn't do much OOP at all to understand the difference.
@@harag9 You can make class implement a type if that type is nonunion object-like type. No any difference for OOP.
"More OOP" isn't a selling point. For the typical 'business app' types are the way to go as you shouldn't be using interface merging when you control the source anyway.
"in frontend"? In frontend usually doesn't matter because React is Functional Programming orientated, not because is frontend. You can write backend code in Functional Programming too, in my opinion if you're writing a API you SHOULD write it in Functional Programming, using OOP for unidirectional events is mostly overhead, and in TS can lead to very bad code, for example Nestjs with decorators.
@@adambickford8720 This is the wrong way to frame the topic. It shouldn't be "just use types" or "just use interfaces". For beginners there's already a sufficiently simple heuristic that you shouldn't have to say something so blunt -- object types are restrictive whereas interface types are permissive.
I use interfaces to enforce the shape of classes.
Excellent video. I like how fast you speak because you get across what you want to say really quickly.
There is one advantage to using interfaces that I don’t see mentioned anywhere else. The “references” CodeLens on object properties currently only works with interfaces. So for instance, if you call an api, pass that data to different components all over your app, and make an interface for the returned data instead of a type, you can find all references to the functions or files that consumes that property or find all properties that have no references at all just by glancing at the interface. This can be pretty useful but I’m still team Type.
Yes no one seems to to talk about it. But this could be improved bye the ide
If u going for an OOP approach when building ur app using interfaces is a must also many of the design patters use interfaces so it depends type and interfaces they both have their use cases
When i started to learn typescript i used interface wherever i could. Couple years ago i switched to use types everywhere and only use interfaces for OOP purposes and I don't even know the reason I switched. But from my experience, most of the times you will do fine using one or another. (for instance a simple component props definition).
You should always go interface first because its more readable, declarative and it inherits. Perfect for classes and objects, an arrays can use enums. Then there are generics, extremely powerful in interfaces where usually my custom type starts. But you do you.
I think Interfaces has a huge beneficial use case when working with data the application don’t have control over, ie API calls. I use Interfaces to describe what I get back from the API call. This makes it very useful because you get the intelisense from VScode to help you. If it is data that you control via the application why don’t use class? Then you can create, user for following the video example, New user.
I’m fairly new in the industry but I had a very experienced teacher and this approach was easy to understand for me.
I'm originally an OOP programmer and so I like to use inheritance. I like to define interfaces that can extend each other.
declaration merging can be really handy for exposing interface types from a library, especially when merging with a namespace declaration, e.g.
export interface User { ... }
export namespace User {
export is(obj: any): obj is User { .... }
}
Wow, great explanation, thanks a lot! 👍
I feel like intention matters too, especially for maintenance. Interface has a very clear definition across languages. And, that context should be preserved in typescript too. With that being said, I do end up using type more than interface, but I consistently use interface when I’m creating an abstraction/contract and type when I’m creating a type of something. I appreciate when I am in a codebase that does this consistently.
I cannot agree with these reasons at all. Interfaces come from the world of polymorphism (and OO for that matter), while types come from the world of JavaScript being a free for all weak type system, where anything can be anything and thus types are a mandatory feature. Union types make absolutely no sense in case of polymorphism and therefore you don't need them at all in this case. If you decide to refrain from polymorphism that doesn't mean that Interfaces are useless, it's just means you are having completely different approach in modelling your data structures.
This answers a question to another video of yours! Thank you thank you thank you!!!!
Excellent explanation! 👏🏻
I use interfaces for function props and class definitions and types for everything else.
I define the interface once then use it to "implement" the class and also to write the validation schema.
honestly, if we spend _some_ time learning about the behaviour of interfaces, then they aren't even hard at all. They also do provide more benefits than types especially in libraries because they can be extended.
But I wouldn't say that types vs interfaces should be a debate, its more of a pref. I personally type objects with interfaces and use types for everything else. Just be consistent with the pick
Yeah, you got me on to the type train a while ago, and now nobody is telling me otherwise. I like interfaces for the naming convention only.
Type status = "complete" | "incomplete"; is one I love very much
I use interfaces mostly as originally intended and types for primitives and unions, but the implicit/silent partial interface extension seems a bizarre "feature" that I've never come across over the past decade... but now seems very scary!
in general Type aliases offer a more convenient way to use utility types and describe tuples, while interfaces can also achieve the same but with a less elegant syntax.
There's some dodgy stuff with interfaces that makes indexed type aliases into them a bit dodgy, something to do with how under the hood they're like Record. I do however like interfaces for when it's expected that you implement them for a class, especially since that then fits the naming convention from other languages.
All those debates still won't stop me from using only Interfaces for defining structures and using Types only for the computed types. Maybe I'm just a weirdo, but at least to me it seems logical that interface should describe _a thing_ and a type, well, describes what type the properties of that thing are unless there are more structures inside. For me it's still just a matter of preference 🤷♂ structure = interface, it's just my C# side
Interface is for declaring class in OOP and type is for declaring Datatypes.
Dude, how are you so spot on all the time??
I too use type unless I need interfaces (I recall needing some advanced generic types in reducers that could only be done with interfaces)
You can just use the | operator at the variable definition level, or am I wrong? This actually feels like cleaner code to me, because you define your interfaces, and at the var level you define which types to adhere to. And if you use interfaces in that way, I don't see the purpose of renaming base types (losing both advantages you summed up).
I'm still pretty new to typescript (though not to programming), so still figuring things out...
like:
interface i1 {
name: string
}
interface i2 {
age: number
}
const user : i1 | i2 = { name: "test" }
I don't know that I agree so much with this. To me, having interfaces and types in my project is actually a huge benefit, because if you see an interface, you immediately know what it is. Whereas if it's a type, you have to either start playing around with it, or look up the definition to see what it is.
I think you missed one very important point. In debug when you do types, you never see where the fields come from. If you have a type that combines 5 others, you don't see it in error messages: you see the whole type definition but not what comes from where.
Interfaces in this respect behave more like in Java or C#: you always see which interfaces a class implements and which field comes frome where
Basically complex types combinations (with | or &) basically create a completely new type without remembering where fields came from. Interfaces always remain named entities
Moved on from curly brackets. Consistency in approach. Pitfalls of one vs other is could to know if you didn't already.
very useful! thank u
Thanks for this!
I'm kinda surprised, given Kyle's previous tutorial videos where he uses types, that he didn't mention that the biggest benefits of using types is they can be combined with utility types to create the desired type from different types/interfaces. Things like Awaited, Partial, Readonly, etc. Example, you can't define an async/await function type with interfaces or types alone but you can do it by combining a type with Promise and Awaited.
I think you misunderstand what an interface is. An interface is like a "descriptor" = it describes how you can use the object (what properties you can expect, as well as what functions it provides).
Here is an example:
interface cat {
name: string;
age: number;
meow(): void;
}
class Cat implements cat {
name: string;
age: number;
meow(): void {
console.log('meow');
}
// but your class can have other properties and methods too
color: string;
}
@@heiko3169 I know what is an interface in typescript. I'm saying that both types and interfaces can be used together with utility types to create very powerful types that otherwise cannot be created with types or interfaces alone.
Awesome video thank you
Also, don't forget the object manipulation you can do for the type keyword:
type MyType = {
[K: string]: string;
}
type MyOtherType = {
[K in keyof object]: number;
}
That's a good one too! Mapped types are very helpful.
I guess one useful feature of interfaces is also that they can be implemented by classes, right? Or can that be covered with types as well?
sure you can do that with types no problem
@@dasten123 Awesome, I wasn't aware of that - thanks :)
If you ignore OOP using only the type keyword may be fine.
To clarify on the interface and type keywords:
Implicitely when you define a data structure with no values, you are defining an interface, e.g. { val: string }
To use it you give the interface a name, e.g. interface Foo { val: string }
The type keyword is a bit misleading. It is essentially an alias for an interface or a combination of interfaces, e.g. type Bar = string | Foo;
Writing type Foo = { val: string }; is essentially defining an interface with no name and assigning it to an alias. Why create an alias of an interface instead of using it directly?
In programming it‘s always better to use the simplest/minimal approach:
If you can use primitive types use them instead of complex interfaces/objects.
If you need simple data structures use interfaces.
If you need union/or types use the type keyword.
it is also possible to "extract" a type definition out of an interface if you need to.
interface User {
name: string;
age: number;
}
const name: User["name"] = "Byron";
I feel like this is possible with a type definition also?
@@offroaders123 not in my experience, but I'd love to see a playground that proves me wrong. I've only needed/wanted to do this a few times, so it isn't a compelling reason for me to personally use interfaces or types all the time.
It is possible to "extract".
interface UserI {
name: string;
age: number;
}
const usernameI: UserI["name"] = "Byron";
type UserT = {
name: string;
age: number;
}
const usernameT: UserT["name"] = "Byron";
I feel like the example you give of the "advantage" of types is a bit contrived - If you are really just using a single "type" then you should either let the ts-interpreter automatically infer the type, *or*, just define the type inline, no need for a Type definition if something is really just a string.
amazing, thank you dude
can you explain single signin for multiple applications with react like share the authentication if i try to redirect the link to second applicatiom from 1st application it should not ask auth again when i already login from 1st app with aws-amplify how?
이거 궁금했는데, 감사합니다. 잘 보았습니다.
I believe that borrowing interface and type definitions from other languages can enhance your understanding and application of each concept.
For instance, I prefer working with definitions from Golang because it benefits from the fact that both JS and Golang are functional languages.
So, I agree that this recommendation sounds a bit off.
Thank you for the video and for the subject!
Thanks kyle good stuff.
I use types for modeling data (e.g. type User = { name: string }) and interfaces for modeling behavior (e.g. interface UserService { getById(id: Id): User })
In my opinión, the only way someone could opt for types instead of interfaces IS because someone tought you that way or your background is not classic POO unless you need types specific features. Anyway you did well with the video title, Its your opinion, everyone have one, pick your best
Just want to take this chance to thank you Kyle for your tutorials. Your videos were one of the main reasons I landed a ReactJS job. Truly appreciate you! Greetings from Philippines. :)
I appreciate your work
You can compose types from interfaces more easily by combining multiple interfaces together
Great information video
i'm usually use interface if i want to pass a type on an object.
Type i usually use when i want to combine a type or create union type
Interface1 & Interface2
"one" | "two" | number
my question is should i use I before the name of the interface? eg, IUser, ITemplate, IBook
The point that’s often missed is the meaning of interface. To me interfaces are more strict and types are more loose. In other programming languages interfaces are often also called „a contract“ and I define typescript interface the same way. I generally use interfaces for retrieving data and then the getData satisfies the contract, the interface.
Also the only reason you can define objects as types is because a js object is actually a type, that doesn’t you should use types everywhere.
But in general I don’t think it is ground breaking deal if you use one over the other.
Would you cover making a type definition library with typescript for a vanilla javascript library to improve intellisense?
Does this overriding of interfaces with the same name happen as well if they're in different files? because that could be a problem
If the file is globally-scoped, yes. But if it's a module, it will not merge. Even when each is exported from those separate modules, they will not merge. So modules can really help prevent things like that.
@@offroaders123 nice, thanks for clarifying.
I don't see why you would oppose using both, doesn't complicate the code at all.
Simply advocating to use types everywhere because it's one unified thing across your codebase is not the best argument. That's like saying "we'll always use `let` because you can do more than with `const`, so if you only use `const` you'll have to switch some to `let` and then you'll have a mix of `let` and `const` in your code".
Think the last "advantage" of interfaces is a code smell in general. You should not be required to extend external objects and it will break if the interface is renamed on a version update, you are basically coupled to the libraries version if you do this. Maintenance nightmare... And for objects in the own repository you could just create a wrapper or extend the existing attribute.
I totally agree about this, use type by default
You can actually use interface with single types. For example like this:
```
interface IString extends String {}
const val: IString = 'foo'
```
What is the usecase for the first reason? I simply can write const user:string ='bla'
why should i make an "alias" for a simple string?
In practice, one of the biggest differences is the IntelliSense. Interfaces hide their properties / fields and replace them with the interface name. They're basically an alias. Types will always show up as their inner structure / fields in IntelliSense.
Example:
interface Point {
x: number
y: number
}
let p: Point
Intellisense will show p as "Point"
type Point = {
x: number
y: number
}
let p: Point
Intellisense will show p as "{ x: number; y: number}"
This is not the first video I see about types and interfaces and every time it is about the declaration of some object or primitive. You can choose whatever you want to describe your data, it mostly depends on your context anyway. However, I haven't seen anybody talk about the usage scenario of each. For instance, if you have a function with a parameter, declaring that this parameter is an Interface will enforce the value passed to this function to at least matches the interface declaration! The value itself can be declared as a type, a class, an anonymous object. I feel this feature is underrated and never included in this kind of discussion. Cheers ;)
Doesn't that work exactly the same if you use a type instead?
@@ollierkul ye it does. typescript is a structural language so the usecase hes describing is completely the same for types
Coming from OOP into TS I perceive the type/interface distinction to be very poorly designed. There are no clear use cases, they both kinda do the same thing but they don't, the naming is unintuitive, it feels disconnected from JS, and I end up just using what works and fix it when it breaks, which is what TS was supposed to prevent me from doing, or change type/interface on the fly to fit my needs forcing me to be aware of all the other code that references the type, and for a big project - it's painful. It feels like I am fighting with TS all the time. Why isn't there smth like @extendable decorator that you put before a type that lets you extend a type? IDK, it makes no sense to me.
Exactly my point. TS creates its own incomplete paradigm and did not borrow from accepted better ones
There is a second benefit, errors will not include type names, interfaces most of the time do. Unless things changed since last time I worked with TS
I use interface for classes and types for objects
I feel like commenting on this will be pointless...
I use objects 90% of the time to pass data around.
When you need a simple argument for a function you do NOT need a type defined for it because you can inline the type and inference does the rest.
Same goes for creating variables, you just inline the type.
If you need a union of 2 objects then you make a union type from the interfaces.
Interfaces hold you accountable for thinking about what you make and use instead of lazily creating types for everything that doesn't need it.
Most of the cases you don't even need to export your interfaces unless you plan to use them inside a callback or something similar.
It's funny how much flack I get for using classes and enums when they come with many benefits if you use them correctly.
If you're using mostly Classes in TS, without a doubt your introducing unnecessary overhead to your code, and in my opinion that's very bad. You're like going against the language trying to recreate OOP only languages.
Why is creating types lazy while interfaces are not? You can create an object type and specify that a class implements that type, just like with an interface. I don't see any benefit from using an interface.
If interfaces are derived from OO languages like Java etc an interface would be used to model polymorphic behaviour and not specific pojo types. I do agree that Type’s work for pojo style objects but interfaces should be used to model behaviour so you can have multiple implementations of a class component that implement that interface.
I dont see the first problem as a problem. Seems same like saying "you can use either let, or const". It is not complicated or harder to read, both have its use cases, so use it. If you use interfaces, but types for single types/unions, why not?
Im pretty sure both exist for a reason and in every case it makes sense to decide to use one over the other. There is recommendations that you should use the smallest type possible of things. If types are a superset and you dont neet the additional features of types, it doesnt make Sense to use them.
You actually made me "wtf" out loud with the 6:50 part. Theoretically this can end up in a super akward situation but practically, at least I never ever accidentally did this in the past 7 years of TypeScript programming 😅
That should actually never happen. You define the User interface in the User.ts file = at 1 place .. and only there. Interface and type definitions have to be in a sole place (file) and nowhere else.
Only thing I find problematic with interfaces is the merging. Many times I like to have a type "Props" for example, that is isolated per file, and if I use an interface, they all merge in the end, and that makes it a little complicated when working on large projects. Suddenly for a component, you have 20 props, when in the definition file you specifiy like 3.
I think the best way to accommodate for this is to use modules to break up your components, they will be scoped to each file, allowing you to use multiple of the same-named interface if you'd like to. Personally I like to name them uniquely to align with the name of the component so I can export it from the module as well, but if it's local to only the module, then I think it's ok if you all name them the same 🙂
You can use it like this:
interface YourComponentNameProps {}
export function YourComponentName(props: YourComponentNameProps) {}
Don't really have an opinon on this yet but I started doing this in my code: `React.ComponentProps`. I don't find that I'm often using props outside of the component instance, but when I do I reach for this. Especially when a 3rd party doesn't export them.
Why define a type or interface outside of your component declaration when you could inline it. Which has the benefit of intellisense showing the exact prop types instead of "MyComponentProps":
export const MyComponent: React.FC = ({ isDisabled = false, color = "red", name }) => { ... };
@@dhedarkhcustard Defining it separately allows you to use the props as a specific type elsewhere in your codebase, simply by importing it. I guess you could also do that by extracting the parameter types of the component elsewhere yourself, but importing the interface itself seems a little more simple I feel like. Maybe it depends though. And if the props get too big over time, then having the destructuring and the type annotations in the same place can get larger over time, making things a little more cluttered. I want to try inlining it now though, like you said it does seem more simple to have them all in one place!
Interface is used for general object types, and types should only be used when there is something that you cannot do (or simply really hard to do) with interfaces
If you find it hard to read it's just skill issue
All the things you said are impossible to do with interfaces are indeed possible using TypeScript's utility types. Although I agree that types will mostly end up being more readable.
*type - defines what something is.
*interface - defines what is the origin of something.
today i was wondering whether i should use types or interfaces and Kyle published a video about this 😅
Pity most of his advice in this one is rather bad.
Thanks!
I default to using types for one reason. I have little need for behavior-related stuff, which is what I would normally use an interface for.
Interfaces don't emit any code, just like types.
@@ChristopherHaws90 Huh... I must be confusing it with something else. Regardless, I'll still use types over interfaces because I associate interfaces with behavior and not data structure, so it doesn't really change much. Thanks for letting me know though. Do you perhaps have any idea what I might be confusing it with?
@@ChristopherHaws90 I remembered what I was thinking of when writing the comment! Enums!
If I recall correctly, another feature exclusive of interfaces is the ability to define overloaded methods.
I do prefer types in most cases though!
That's a great one also! I can't remember if it's with the & or the | operator, but I think you can create overloads with the type keyword using those operators as well.
the last example at 7:14 is not super correct because its in the same file I think? also another thing that idk if its actually useful is that u can define properties to be readonly at the interface level and then for example keep them non-readonly in the implementation, but on the other hand to achieve the same you can just do (this as { readonlyProperty: string }).readonlyProperty = 'newValue'
Well, I use interface, generics and types as well.
Totally agree
After reading the comments I'm convinced that the people hard disagreeing with this take come from the world of OOP and are just used to interfaces. It seems many people don't realise classes can implement types, just like interfaces. In pretty much any situation you would want an interface it can be substituted for a type. So, why is this such a hot debate?
Clarity: they do different things 🙂
Interfaces is nice for inheritance
Pretty sure you can do interface SInter { name: string | number } with no problem. I use Angular & never create my own types.