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.
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!
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.
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.
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.
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
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.
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 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.
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.
@@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.
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.
@@King-Gilamashur2758 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-Gilamashur2758 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.
@@soviut303 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?
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.
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.
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.
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.
@@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.
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 .... 🙃
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*
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*
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 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
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.
"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.
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.
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".
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; }
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.
I would generally use interfaces as long as they are faster, but aliases have one major feature, means mapping type MappedTypeWithNewProperties = { [Properties in keyof Type as NewKeyType]: Type[Properties] }
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?
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).
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";
@@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.
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 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
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
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 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.
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
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 use types for modeling data (e.g. type User = { name: string }) and interfaces for modeling behavior (e.g. interface UserService { getById(id: Id): User })
Reason 2 ... could've just done: ``` type SType = {name: string} | {age: number}; interface Test { name?: string; age?: number; } ``` now you should be able to do `const foo: Test = {age: 1};` or const bar: Test = {name: 'hello'};` OR EVENT `const foobar: Test = {name: "hello", age: 1};` you dont have to create a whole new interface to add a new property to an interface, adding `?` makes the prop optional also.
I went straight to interface because I came from other programming languages and it just made sense. I've been using interface for many years and in production with typescript code and never actually had a problem. Typescript actually has namespaces to prevent collision of reuse. Maybe start using namespaces in your coding?
Anytime someone starts speaking in absolute terms (using words like "always") you know you need to take what they're about to say with a grain of salt.
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.
Should you use strings or numbers in your code? Some sources claim that the number type is for representing numeric values while the string type is for text but that's just confusing and makes your code hard to refactor. You should always use strings as they have more features. Any number can be written as a string whereas the opposite isn't true. There's however this tiny little drawback that you can't do any math with strings but that's an edge case you probably won't run into. Worst case scenario, you can always use a library. So don't listen to people who say different features are meant for different purposes; if you can do everything with one feature, then don't overcomplicate your code unnecessarily.
@@montebont JS only has floating point numbers, there is no distinction between integers and floats in the language, so it makes sense for the types to reflect that
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.
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!
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.
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
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
type cannot be overwritten but you can overwrite interface.. for example use type to model and validate data type in the props of a UI component, so imagine you are bulding e-commerce application you have a customer object from a data base this object has a lot of connections to order object and other objects, and you're in the front-bulding an `order-history` page for the customer, your component will need order history list of specific customer and maybe a links to products in this order list and date or maybe payment method or delviery type now you're infornt of a combination of data types from more than one object, then create a `type` to model and validate the data for your UI component, you can use interface ofcourse but interface meant for customer object itself while type it could be a data in UI props or state.
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 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.
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 ;)
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.
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.
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.
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.
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.
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.
Truly disappointed with this video. Typescript literally tells you "Use interfaces until you need the features of types", but then Kyle makes a video listing all the features of types and saying that's why you should always use types, whether you need those features or not (and a lot of the time, you really don't). Types serve a purpose, interfaces serve a purpose, you should've rather made a video explaining how to know when to use types or interfaces. And the whole mixing types and interfaces in the codebase comment is bogus, that's like saying "Always use 'const' instead of 'let' because const has all these features and let only does this"... Seriously Kyle 🤦♂💔
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.
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.
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. :)
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" }
У JavaScript - все как всегда! Сначала был - lagecy, анти паттерны теперь к ним прибавился - typescript. Теперь программирование на JS становиться на порядок опасней - чем раньше.
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 RUclipsrs 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
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.
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.
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.
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-Gilamashur2758 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-Gilamashur2758 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.
@@soviut303 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?
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.
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.
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.
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.
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*
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 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
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.
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'm originally an OOP programmer and so I like to use inheritance. I like to define interfaces that can extend each other.
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 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.
Thanks Kyle! I'm really trying to step up my game at work and I appreciate the typescript content.
Type status = "complete" | "incomplete"; is one I love very much
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".
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 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.
I would generally use interfaces as long as they are faster, but aliases have one major feature, means mapping
type MappedTypeWithNewProperties = {
[Properties in keyof Type as NewKeyType]: Type[Properties]
}
Excellent explanation! 👏🏻
I use interfaces for function props and class definitions and types for everything else.
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 🙂
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).
Wow, great explanation, thanks a lot! 👍
Interface is for declaring class in OOP and type is for declaring Datatypes.
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";
Dude, how are you so spot on all the time??
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.
This answers a question to another video of yours! Thank you thank you thank you!!!!
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
Well, I use interface, generics and types as well.
*type - defines what something is.
*interface - defines what is the origin of something.
Excellent video. I like how fast you speak because you get across what you want to say really quickly.
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
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 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.
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
You can actually use interface with single types. For example like this:
```
interface IString extends String {}
const val: IString = 'foo'
```
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 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 define the interface once then use it to "implement" the class and also to write the validation schema.
Reason 2 ... could've just done:
```
type SType = {name: string} | {age: number};
interface Test {
name?: string;
age?: number;
}
```
now you should be able to do `const foo: Test = {age: 1};` or const bar: Test = {name: 'hello'};` OR EVENT `const foobar: Test = {name: "hello", age: 1};`
you dont have to create a whole new interface to add a new property to an interface, adding `?` makes the prop optional also.
I went straight to interface because I came from other programming languages and it just made sense. I've been using interface for many years and in production with typescript code and never actually had a problem. Typescript actually has namespaces to prevent collision of reuse. Maybe start using namespaces in your coding?
Anytime someone starts speaking in absolute terms (using words like "always") you know you need to take what they're about to say with a grain of salt.
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.
I totally agree about this, use type by default
Should you use strings or numbers in your code?
Some sources claim that the number type is for representing numeric values while the string type is for text but that's just confusing and makes your code hard to refactor. You should always use strings as they have more features. Any number can be written as a string whereas the opposite isn't true.
There's however this tiny little drawback that you can't do any math with strings but that's an edge case you probably won't run into. Worst case scenario, you can always use a library. So don't listen to people who say different features are meant for different purposes; if you can do everything with one feature, then don't overcomplicate your code unnecessarily.
I agree: the "number" type is hardly useful because it doesn't specify integer or float nor its base (2, 8, 10, 36)
@@montebont JS only has floating point numbers, there is no distinction between integers and floats in the language, so it makes sense for the types to reflect that
Pro tip :
If you’re defining an interface, use interface
If you’re defining a type, use type
You’re welcome
🙂
I’d be surprised if anyone took anything away from this video. Pure waffle.
very useful! thank u
Awesome video thank you
I use interface for classes and types for objects
Great information video
You can compose types from interfaces more easily by combining multiple interfaces together
I don't see why you would oppose using both, doesn't complicate the code at all.
amazing, thank you dude
Thanks for this!
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}"
Moved on from curly brackets. Consistency in approach. Pitfalls of one vs other is could to know if you didn't already.
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!
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 appreciate your work
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
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
type cannot be overwritten but you can overwrite interface.. for example use type to model and validate data type in the props of a UI component, so imagine you are bulding e-commerce application you have a customer object from a data base this object has a lot of connections to order object and other objects, and you're in the front-bulding an `order-history` page for the customer, your component will need order history list of specific customer and maybe a links to products in this order list and date or maybe payment method or delviery type now you're infornt of a combination of data types from more than one object, then create a `type` to model and validate the data for your UI component, you can use interface ofcourse but interface meant for customer object itself while type it could be a data in UI props or state.
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 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 heard the same before from experienced developers. Use interface, until you need types
Can class implement type?
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
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.
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.
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 too use type unless I need interfaces (I recall needing some advanced generic types in reducers that could only be done with interfaces)
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.
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.
Would you cover making a type definition library with typescript for a vanilla javascript library to improve intellisense?
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.
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.
Truly disappointed with this video. Typescript literally tells you "Use interfaces until you need the features of types", but then Kyle makes a video listing all the features of types and saying that's why you should always use types, whether you need those features or not (and a lot of the time, you really don't). Types serve a purpose, interfaces serve a purpose, you should've rather made a video explaining how to know when to use types or interfaces.
And the whole mixing types and interfaces in the codebase comment is bogus, that's like saying "Always use 'const' instead of 'let' because const has all these features and let only does this"...
Seriously Kyle 🤦♂💔
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.
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.
이거 궁금했는데, 감사합니다. 잘 보았습니다.
interface SType {text: string} easy man.
And That IS WHY they recommend you should use interfaces unless you need types, because interfaces are much simpler
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. :)
This is the type of video that confuses people that are starting and discourage the devs.
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" }
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
У JavaScript - все как всегда! Сначала был - lagecy, анти паттерны теперь к ним прибавился - typescript. Теперь программирование на JS становиться на порядок опасней - чем раньше.