Using Types in Typescript favors for Functional Style Programming. You can compose complex types from simple types. Using Interfaces tend towards an OOP Style. You define the shape of objects. You can mimic an object hierarchy with interface merging (intefaces with the same name merge into one)! For me: Composition over Inheritance!
I think this is the better recommendation, especially in JS/TS world where more people prefer composition in general (e.g. React functional components instead of Class components now we have hooks). I think inheritance and interface might be more familiar to people coming from from OOP languages, but going with Types will just make you practice composition programming more.
I never understood this mindset. You can write OOP with composition instead of inheritance, too. Traditionally, interfaces _are_ for composition. You distill an object into constituent parts and create an interface for each of those. You can then reuse them as you see fit.
I still like interfaces for defining the shape of all the data my APIs return. I usually only reach for types when I need a functionality that interfaces don't provide (as mentioned in this video, is no longer a very big feature set)
Just another "OOP bad, Functional good!" comment. Why not use both paradigms? Composition over inheritance can be achieved with any paradigm. OOP Example: You can create different interfaces without extending them and have the concrete class implement whichever interfaces it needs.
three unique features that interfaces have: 1. It is more geared towards objects, classes and functions 2. It can extend 3. It supports declaration merging
No, the only difference is that interfaces can be declared again and be merged into one. type is not. Please see document: www.typescriptlang.org/docs/handbook/2/everyday-types.html#differences-between-type-aliases-and-interfaces
Declaration Merging: The same name of Interface declarations can be do merging, while types cannot because it is fixed and static shape of object. Types merging is by union and intersection Interface is the better choice when you write a library to export because interface could be extended and change to fit the needs of library client. If you use objects and classes, use interfaces as well. Otherwise use types.
“I just had lunch... and it was delicious.” Hilariously said; actually did make me laugh out loud. Love your comfort level on camera... something I will now strive to obtain.
My recommendation is to use types exclusively for the simple reason that everything can be typed with the type keyword, but not everything can be typed with the interface keyword. Additionally, if you need to modify an object type, you can do so with the TypeScript global generics e.g. Omit, Required, and Partial.
We can say interface is a contract that the implementing class,function or object must fulfil. But unlike interface types can’t be inherited. Nice video Harry . make a video on generics as well !!!
Harry, thank you for this! I tend to be an interface person myself.... except when it comes to defining any kind of function, then it's straight to types. Absolutely agree with this video, haha! Great content as usual. :)
I love the fact that you gave me an actual answer in the begining, so many people enjoy wasting time or fill space I guess. (Still watch to the end :))
It would be cool if when you typed the Interface name, there would be a snippet that auto completes the object and places the cursor on the fields. So at 3:10 typing Person there should be a snippet for “= { name: $1, hungry: $0 }
Nobody can seem to get this right, interfaces , classes types come from typed language based on traditional oop principles. Considering the author of typescript is the same author of c# it's easier to think if them I their traditional terms used in languages like java, c#, c++ etc. An interface normally defined a CONTRACT that a type MUST adhere too, traditionally an interface does not and can not have state. A type or class type on the other hand CAN have STATE and provide base functioning that can be overriden. If you don't adhere to these rules/definitions then they both from a practical standpoint in typescript become the same....
q1.Write a program to define a class called Student properties rollno & name. Also create functions for reading and display these details. Then Define interface named GraceMark with property mark initialized to 10 and a function called readMark() to read marks. Then define a class called Result with properties mark1, mark2 and function total () for finding the total mark q2.Accept a number with 1-7 and print the corresponding Week, don’t use if statement. can u
People are discussing the use of Interfaces VS Types. Could you not use Interfaces composed of types to overcome the shortfalls of both? Or would that create different issues?
Harry, was waiting for this video, it's very useful and easy to understand. Also must say your house/bedroom is very nice and clean. I hope I can build a house like yours.
Thank you Harry, Is there any convention to where to store interfaces and types within a react project? e.g: in the same file or make a separate folder/file for them.
Loved the way you explained this. I realized I already knew most of this, but you definitely got a subscription because of your delivery! I’m one to your Next.js with Tailwindcss videos next! Keep making videos! Thanks!
Harry Wolff there are a lot of videos on typescript basics but very few on the best typescript practices in a real app. For example, what should we do with .d.ts files? Should we put all type declarations in one file and export/import them? Perhaps walk us through a real open source app that uses typescript and call out the best practices and why the app using typescript this way.
Hi. Thank you for the video. I am a noob at TS. When talking about functional interfaces at 3:59: line 18 I would have just put (name: string). What is the purpose of adding : string; ?
Or I can confuse myself by using types inside interface like type name = string interface IPerson { name: name; } But don't do it because it is stupid.
This could actually be helpful! For example, imagine you have a property for temperature and you have some functions that transform it between celcius and fahrenheit. Being able to specify which system is being used can be helpful to making your code more readable, even though it won't necessarily add any real safety. However this isn't super helpful currently, since TS loses the alias and doesn't use nominal types, as is mentioned in the video.
"APIs should be open to extension, so use interfaces over types". This does not apply to typescript _at all_ (anymore?) (also, can you point to the source in the TS docs? I remember this as well but can't find it now). You can create an interface that extends a type and the other way around by using the intersection operator as long as the consumer of your api uses a compatible typescript version (and if not, is it really your responsibility?). The only thing you can't do with types (afaik) is declaration merging, and well, let's not go down that rabbit hole here. But you can do more complex stuff, like an xor type, mapped types, conditional types and so on. Granted, the actual parts of such a type alias can be interfaces or types, that doesn't matter, but I like consistency here. Also, "interfaces are for objects" sounds like it implies that "types are not for objects", and I don't see any reason why that should be the case? Both interfaces and types can describe objects since they both describe shape and that's about the only thing that matters to js. No matter if you mean objects that only carry data or objects that "encapsulate data and behaviour" as in "instances of classes". Personally, I only use type aliases because I feel like interfaces introduce a notion of OOP into the codebase and they hint (for me) to the use of classes and I have spent too much time of my life already debugging OOP code which is why I dislike it. I.e. "use interfaces if you want to go the OOP route and use type aliases if you want to do FP or if you prefer a single syntax to be used everywhere and don't mind not using methods". On the video itself: I think you structured it well and your examples are well thought out, easily digestible and approachable. I'll keep an eye on your channel :)
10:40 seems weird behavior because it also seems Harry is Union of Person AND|OR TH-camr rather than Harry is Person or TH-camr. needed an explanation for that. I think you were also not expecting that judging by your reaction. ?? @harry
"The short answer, and the one that let's you stop watching this video..." Bravo
Using Types in Typescript favors for Functional Style Programming. You can compose complex types from simple types.
Using Interfaces tend towards an OOP Style. You define the shape of objects. You can mimic an object hierarchy with interface merging (intefaces with the same name merge into one)!
For me: Composition over Inheritance!
That was my thought also. When an interface is extended, changing the interface may break children interfaces.
I think this is the better recommendation, especially in JS/TS world where more people prefer composition in general (e.g. React functional components instead of Class components now we have hooks).
I think inheritance and interface might be more familiar to people coming from from OOP languages, but going with Types will just make you practice composition programming more.
I never understood this mindset. You can write OOP with composition instead of inheritance, too. Traditionally, interfaces _are_ for composition. You distill an object into constituent parts and create an interface for each of those. You can then reuse them as you see fit.
I still like interfaces for defining the shape of all the data my APIs return. I usually only reach for types when I need a functionality that interfaces don't provide (as mentioned in this video, is no longer a very big feature set)
Just another "OOP bad, Functional good!" comment. Why not use both paradigms? Composition over inheritance can be achieved with any paradigm. OOP Example: You can create different interfaces without extending them and have the concrete class implement whichever interfaces it needs.
Best video on this. You gave the answer quickly and simply, but provided enough valuable info to keep me watching the rest
I like how you talked about why to use either instead of just saying they exist. Very nice
Short answer. Thanks for being honest sir. Even though I watched the entire video.
three unique features that interfaces have:
1. It is more geared towards objects, classes and functions
2. It can extend
3. It supports declaration merging
No, the only difference is that interfaces can be declared again and be merged into one.
type is not.
Please see document:
www.typescriptlang.org/docs/handbook/2/everyday-types.html#differences-between-type-aliases-and-interfaces
Bro the best thing anyone has ever done, short answer first!
Declaration Merging: The same name of Interface declarations can be do merging, while types cannot because it is fixed and static shape of object.
Types merging is by union and intersection
Interface is the better choice when you write a library to export because interface could be extended and change to fit the needs of library client.
If you use objects and classes, use interfaces as well. Otherwise use types.
“I just had lunch... and it was delicious.” Hilariously said; actually did make me laugh out loud. Love your comfort level on camera... something I will now strive to obtain.
My recommendation is to use types exclusively for the simple reason that everything can be typed with the type keyword, but not everything can be typed with the interface keyword. Additionally, if you need to modify an object type, you can do so with the TypeScript global generics e.g. Omit, Required, and Partial.
We can say interface is a contract that the implementing class,function or object must fulfil. But unlike interface types can’t be inherited. Nice video Harry . make a video on generics as well !!!
Generics you say?!?!!? th-cam.com/video/nePDL5lQSE4/w-d-xo.html
interface can be inherited. T extends R. class can be used to create instance, that’s difference
@@tranhuuthu991990 He said that types cannot be inherited, but interfaces can.
Harry, thank you for this! I tend to be an interface person myself.... except when it comes to defining any kind of function, then it's straight to types. Absolutely agree with this video, haha! Great content as usual. :)
Very glad we agree! Always scary putting my opinions out there and seeing what people think 🙈
I like types for restricting values - type Thing = 'foo' | 'bar'
Holy cow, what a deep voice you have!
For me listening to this video was like a flashback of me playing "Splinter Cell: Chaos Theory" a long time ago)
I love the fact that you gave me an actual answer in the begining, so many people enjoy wasting time or fill space I guess. (Still watch to the end :))
It would be cool if when you typed the Interface name, there would be a snippet that auto completes the object and places the cursor on the fields. So at 3:10 typing Person there should be a snippet for “= {
name: $1,
hungry: $0
}
Nobody can seem to get this right, interfaces , classes types come from typed language based on traditional oop principles. Considering the author of typescript is the same author of c# it's easier to think if them I their traditional terms used in languages like java, c#, c++ etc. An interface normally defined a CONTRACT that a type MUST adhere too, traditionally an interface does not and can not have state. A type or class type on the other hand CAN have STATE and provide base functioning that can be overriden. If you don't adhere to these rules/definitions then they both from a practical standpoint in typescript become the same....
You explained very well. Finally I was able to understand Interface and type
Personally I mostly use types 🌹
Thank you , my friend. this was awsom
Thanks for the quality content. I got an answer to my question and became ur new subscriber
q1.Write a program to define a class called Student properties rollno & name. Also create functions for reading and display these details. Then Define interface named GraceMark with property mark initialized to 10 and a function called readMark() to read marks.
Then define a class called Result with properties mark1, mark2 and function total () for finding the total mark
q2.Accept a number with 1-7 and print the corresponding Week, don’t use if statement.
can u
You forgot the string enum
you can do string enum in types but you can't do that in interface
something like this
type Gender = "Male" | "Female"
How can I use an interface as type?
Of course I can implement an interface as a type.. but what is the other way?
What font is that? Looks amazing
People are discussing the use of Interfaces VS Types. Could you not use Interfaces composed of types to overcome the shortfalls of both? Or would that create different issues?
I really hope to master this Typescript someday
thanks for the short answer, but why a white background? it hurts
what's the different between type Harry1 = Person | TH-camr and Type Harry2 Person & TH-camr ?
Love your video! It's really helpful, but which of them (interface or type) should be used when using Maps?
Just the explanation I was looking for, thanks so much!
Just wow! Thank you!
so, when you unite two types, the union operator behaves like an Inclusive or?
p.s. great tut!
Pretty much! Thank you!
I like this explanation about types and interfaces, thanks!!!
Harry, was waiting for this video, it's very useful and easy to understand. Also must say your house/bedroom is very nice and clean. I hope I can build a house like yours.
Thanks so much for the kind words Mridul!
I'm actually moving at the end of the month where I'll have my own personal dedicated office. I can't wait!
@@hswolff all the best mentor...
great video!! thanks!
Light theme feels like a flashbang
It looks that Interfaces also can be combined into unions just like Types can
i love your honesty keep being you
Thank you Harry, Is there any convention to where to store interfaces and types within a react project? e.g: in the same file or make a separate folder/file for them.
Usually I just store them in the same file that I'm using them, unless they're an interface or type that I'm going to use in multiple locations.
Loved the way you explained this. I realized I already knew most of this, but you definitely got a subscription because of your delivery! I’m one to your Next.js with Tailwindcss videos next! Keep making videos! Thanks!
perfect explanation
Thank you!
Thanks Harry, you are great at explaining things!
Thank you!
More typescript videos please!!
Anything in particular you're interested in?
Harry Wolff there are a lot of videos on typescript basics but very few on the best typescript practices in a real app. For example, what should we do with .d.ts files? Should we put all type declarations in one file and export/import them? Perhaps walk us through a real open source app that uses typescript and call out the best practices and why the app using typescript this way.
Hi! Thanks for your video. It was released recently after I got this question for myself. What a magic world! :)
Timing is everything :D
Hi. Thank you for the video. I am a noob at TS. When talking about functional interfaces at 3:59: line 18 I would have just put (name: string). What is the purpose of adding : string; ?
That's the return type of the function: (argName: string): returnType
Excellent video! Very informative, thanks!
Nice video bro
fantastic video, thanks
Thank you
Could optional chaining (?) be also used with types ? Thanks for the video Harry (:
Optional chaining can be used in JavaScript with no types or interfaces. It’s unrelated
Wow this was a very good explanation!
Great video!
I used interfaces with unions now it support unions and intersections i guess
You are awesome. I didnt know you, but you have a new subscriber
Hey thank you! And welcome!
Thank you so much for this!
You are very welcome!
@@hswolff I really really really appreciate it so much. This means a lot to me.
Pity this is wayyyyyy old now. You'd do a great job dispelling the ambient mode that's all around us .. waiting. .
Thank for this video. Want something advance. Like Generics
Generics you say?!?! th-cam.com/video/nePDL5lQSE4/w-d-xo.html
Harry Wolff hoho. Thx 😊
Or I can confuse myself by using types inside interface like
type name = string
interface IPerson {
name: name;
}
But don't do it because it is stupid.
This could actually be helpful! For example, imagine you have a property for temperature and you have some functions that transform it between celcius and fahrenheit. Being able to specify which system is being used can be helpful to making your code more readable, even though it won't necessarily add any real safety. However this isn't super helpful currently, since TS loses the alias and doesn't use nominal types, as is mentioned in the video.
And interfaces in types!
"APIs should be open to extension, so use interfaces over types". This does not apply to typescript _at all_ (anymore?) (also, can you point to the source in the TS docs? I remember this as well but can't find it now). You can create an interface that extends a type and the other way around by using the intersection operator as long as the consumer of your api uses a compatible typescript version (and if not, is it really your responsibility?).
The only thing you can't do with types (afaik) is declaration merging, and well, let's not go down that rabbit hole here.
But you can do more complex stuff, like an xor type, mapped types, conditional types and so on. Granted, the actual parts of such a type alias can be interfaces or types, that doesn't matter, but I like consistency here.
Also, "interfaces are for objects" sounds like it implies that "types are not for objects", and I don't see any reason why that should be the case? Both interfaces and types can describe objects since they both describe shape and that's about the only thing that matters to js. No matter if you mean objects that only carry data or objects that "encapsulate data and behaviour" as in "instances of classes".
Personally, I only use type aliases because I feel like interfaces introduce a notion of OOP into the codebase and they hint (for me) to the use of classes and I have spent too much time of my life already debugging OOP code which is why I dislike it.
I.e. "use interfaces if you want to go the OOP route and use type aliases if you want to do FP or if you prefer a single syntax to be used everywhere and don't mind not using methods".
On the video itself: I think you structured it well and your examples are well thought out, easily digestible and approachable. I'll keep an eye on your channel :)
Not all heroes wear capes.
Good video, but please don't use light themes
Awesome!
I came accross a library that doesnt have its types :( "react-graph-vis"
I'm missing your blog :(
What you missing?
10:40 seems weird behavior because it also seems Harry is Union of Person AND|OR TH-camr rather than Harry is Person or TH-camr. needed an explanation for that. I think you were also not expecting that judging by your reaction. ?? @harry
korea subtitle thx !!
Omg so Helpful... Love From India (Keep Make This kind Of videos) Thank you sir.....
Heeeeey! Thanks man. 😊
You are welcome!
I'm always hungry!
ME TOO!!
Uses interfaces in types lol
Find types abbreviate otherwise rather verbose type declarations
You forgot to say "May the 4th be with you" #disappointed
FUCK
The sore creek neuropathologically pinch because birth principally fear except a bent eyelash. same, used begonia
You coded on a white background...😡
this dude really thinks he's the cherno
wow ur so nice and cool i love u (no homo) :)