I Cannot Believe TypeScript Recommends You Do This!
Вставка
- Опубліковано 1 чер 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
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 UA-camrs 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.
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
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.
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.
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?
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
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.
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
I use interfaces to enforce the shape of classes.
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.
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.
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.
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
Thanks Kyle! I'm really trying to step up my game at work and I appreciate the typescript content.
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.
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".
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
Excellent video. I like how fast you speak because you get across what you want to say really quickly.
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 { .... }
}
I'm originally an OOP programmer and so I like to use inheritance. I like to define interfaces that can extend each other.
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).
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
Type status = "complete" | "incomplete"; is one I love very much
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
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.
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.
*type - defines what something is.
*interface - defines what is the origin of something.
Interface is for declaring class in OOP and type is for declaring Datatypes.
Wow, great explanation, thanks a lot! 👍
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.
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
I don't see why you would oppose using both, doesn't complicate the code at all.
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";
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.
This answers a question to another video of yours! Thank you thank you thank you!!!!
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 🙂
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.
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.
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
Excellent explanation! 👏🏻
Thanks for this!
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 })
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!
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
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.
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.
I use interfaces for function props and class definitions and types for everything else.
I heard the same before from experienced developers. Use interface, until you need types
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}"
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.
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.
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.
Awesome video thank you
Moved on from curly brackets. Consistency in approach. Pitfalls of one vs other is could to know if you didn't already.
It's really simple. Type for data. They are equivalent to 'records' in Functional Programming.
Types shouldn't have functionality.
Interface is synonymous to API and contracts. Hence, use them when you are doing services aka functionality.
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.
Thanks kyle good stuff.
very useful! thank u
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?
이거 궁금했는데, 감사합니다. 잘 보았습니다.
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" }
You actually CAN do with interfaces what | does for types: just create third interface and make both types extend from it. I know it's mouthful, but it is possible. I personally lean towards types - they remind me of haskell syntax which warms my heart. Oh, and I also dislike this "extending interface" thing - I'd rather see it explicit, like in C# with "partial" keyword.
I’d be surprised if anyone took anything away from this video. Pure waffle.
You can actually use interface with single types. For example like this:
```
interface IString extends String {}
const val: IString = 'foo'
```
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
Dude, how are you so spot on all the time??
У JavaScript - все как всегда! Сначала был - lagecy, анти паттерны теперь к ним прибавился - typescript. Теперь программирование на JS становиться на порядок опасней - чем раньше.
Would you cover making a type definition library with typescript for a vanilla javascript library to improve intellisense?
This feels like a rather weak discussion on interface vs types.
(1) It's nonsense to say that an interface has a limitation because it can't describe a number or string. Interfaces describe the shape of objects and are themselves a type, and you can create a type which is a union of interfaces.
(2) Framing types and interfaces as interchangeable except for one feature difference (interface merging) is the wrong perspective. When they are comparable, i.e., object types vs interfaces, then types are restrictive and interfaces are permissive. This is the better heuristic, as opposed to "just use types".
(3) The argument that interfaces are faster is not a mainstream argument and is distracting given how weak it is. Even if it were true it'd be a brittle micro-optimization.
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 :)
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.
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.
amazing, thank you dude
I too use type unless I need interfaces (I recall needing some advanced generic types in reducers that could only be done with interfaces)
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 use interface for classes and types for objects
Great information video
Well, I use interface, generics and types as well.
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
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 define the interface once then use it to "implement" the class and also to write the validation schema.
I appreciate your work
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
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.
I think interfaces are better for API responses
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?
May I say that in a world of approximate developers, always in hurry, "restrictive" when features are not needed, or where you are not at all aware in what you doing, it is better(safer?) than "versatile"?
That because when you reach a cul-de-sac using interfaces, you forced to ask yourself "am I proceeding in the right way?", then eventually go for types.
It might impact with the developing speed, but for sure that improves your software design quality.
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!
Pretty sure you can do interface SInter { name: string | number } with no problem. I use Angular & never create my own types.
And That IS WHY they recommend you should use interfaces unless you need types, because interfaces are much simpler
People often mix up these two concepts due to a poor understanding of types and interfaces. The purpose of an interface is to provide type information on classes, and this is conceptually distinct from types like strings, integers, or object literals in JavaScript. Given that JavaScript is prototype-based and object-oriented, the notion of classes doesn't truly exist; it's essentially syntactic sugar to emulate classic object-oriented programming. As a result, the use of interfaces in JavaScript doesn't align entirely with their traditional role.
However, even in this context, there is a correct and incorrect way to use interfaces. Essentially, if one is working with classes, they should use interfaces; otherwise, they should stick to types. This approach reduces confusion and facilitates a smoother transition to working with genuinely object-oriented languages, such as C#.
This is the type of video that confuses people that are starting and discourage the devs.
I totally agree about this, use type by default
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. :)
One point you didnt mention is that in large codebases whether you use type or interface to define types, you will always end up with a barely readable tangled monster of type definitions that get worse and worse until you give up and use the "as" keyword.
Sounds more like a skill issue to me