👉 NEW React & Next.js Course: bytegrad.com/courses/professional-react-nextjs

My rule of thumb is use interface until type is needed. 90% of the times I find myself defining objects

TypeScript, not InterfaceScript

I use interface for objects (which is mostly what I do when defining data models) and type for all else as needed. I don't think they're mutually exclusive. Use them both.

They may do similar things but the concept they convey is different. I use interface as the meaning of the interface that there is in Java/C# or other OOP languages, that is something a class needs to implement. While type is like a struct/record, something that is only used to pass around data, not methods. This way in my opinion the codebase is clear, since you have a separation between two concepts.

Wrote this reply in another reply thread, but essentially it's to answer some people who complain to just use interfaces until you can't. I create an example hypothetical scenario to showcase why this is unnecessary in this reply: I favor always using types just like Wesley explains in this video, because essentially it keeps everything consistent. If you really have the specific case for more complex interface polymorphism, e.g. complex hybrid types, then you will already know you should use interfaces and create that exception. If not, every other case you can use types and make it consistent. To say you use interfaces until type is needed is like saying, if we bridge the example to declaring variables, that when you define an object u do: const obj = { example: 'example string' } and when you "know" you need to not use an object you just use another way of declaring: dec loggedIn = false In this situation, "dec" is a made-up replacement for const / let that stands for "declare variable", where you know you are declaring a variable that is not an object. This is the same as the interface type situation, but if you can do: dec obj = { example: 'example string' } why would u keep switching between dec and const... just use dec all the time. Now back to the video, it's the same with types and objects. If I need a union I use type = type1 | type2 | type3 etc or some type like type = AnotherType[] or type = typeof keyof Anothertype, and if I needed to type an object I have to suddenly swap to interface or vice versa it's just messy. Just always use types, just like you can always use const, even if they add a new keyword to declare variables with objects to allow you to do very specific things that aren't needed often you would still continue to use const to declare both objects and other stuff.

I disagree. Interfaces has limited functions for a reason. It makes it clearer to understand what the code is intended for at first glimpse. Having lack of features is an advantage in this case when it comes to readability. I'm afraid that junior developers will now haphazardly add 'type' to their code after watching this video.

I don't really consider these to be problems... I consider them different use cases. Type I use when aliasing.. Interfaces I use when defining an interface. Call it semantics - because it mostly is. I actually consider the fact that interfaces only define object shapes to be a benefit, it's generally pretty rare that I want to simply alias an underlying / primitive type other than as a placeholder when passing it around. Quite often I'd alias a string as EmailAddress for example but usually because I'm passing the type around and at some point I suspect I may want to replace that type alias with a proper interface without replacing all the areas where the type is passed (of course you have to change the places that actually operate on the type). It's far more common that I want to define a contract for an object so I'm happy using interfaces as that's what they are. I also actually prefer the syntax as it conveys more info (seems more expressive) saying "interface IDerivedThing extends IBaseThing {...}" rather than "type IDerivedThing = IBaseThing & {...}".

That's because interfaces are... well, interfaces. They represent a contract - a set of methods and properties exposed by the object. They are not types. If types were only for primitives, interfaces would make much more sense in TS. Btw, you can create an interface for a primitive too like this: interface Address extends InstanceType {}; It is just not as convenient as with types :)

Interface is for shapes in the form of objects, you can "extend" a shape. With shapes you can build a hierarchy. Type alias is for type composition. you can compose types from simple types. A type is a fixed definition. You can change/omit properties with the help of utility types.

One point in favor of interface is that it can extends from both type alias and interface. A type alias can extends (intersects) from types but cannot from interfaces. When working with third party libs that export props as interfaces, this might be an issue if you strictly use type alias in your project

As a person who new on this typescript world, your video is really understandable. Thank you.

Really appreciate your content man, very useful!

Thank you so much for your video, I just started learning typescript and it's a bit confusing at first, but I'm getting the hang of it

very concise and clear examples. great!

This knowledge is extremely useful when you're fixing someone else's code. You would understand the working 'intent' more clearly (or quicker) knowing the utility and restrictions of each facility. Thanks for the review & lesson.

While it might be debatable what to use, but this is the first time I understood the difference between interface and type. Thanks for that!

I loved the "Type"Script pun. The reason I use Interfaces instead of Types is because when skimming through code Types can confuse me with regular variable assignments. But I totally agree with the video. I wished that maybe something more in between where types don't look like too much like regular code assignment but it would be as flexible as types and less verbose compare to interfaces.

i prefer interfaces honestly because they feel more strict and the extend keyword feels more clean and i find the most complex features of types not really necessary. And ofc interfaces are a concept that exists in other languages. I only use type when i need the union feature. In my company I work on a massive react project with ts and most devs prefer interfaces it gets the work done.

One uses interfaces if they wish to flip the dependencies of a system around, mainly in OO environments like C++, C#, and Java. Javascript has the rule of composition over definition;Javascript follows structural comparison rules and doesn't really care about structural definition comparisons (is it of the same direct type or is it a child of one). Because objects in js follow different rules for substitution, interfaces aren't really as needed in the same way they are needed in the earlier mentioned environments. In js, expecting an object of a type with a function validate means it can be any object as long as their validate matches the expected function header (and even that doesn't have to be true). Typescript interfaces are a bit weird. They are nice, but types are indeed a better alternative.

What do you think about creating DTOs interfaces? I know we can use "Omit" to filter a field but what if someone forgets about that and sends back the entire model to the client.

Very Interesting ! I believe we can also use Pick keyword to assign part of a type

what plugin do you use for this autocomplition?

Which extension makes the object's properties suggestion when creating an object?

What adson do you have installed to give you completion suggestions?

A bit skeptical at first but this makes sense! Thank you for sharing.

What a great video! I understand now many things what’ve not understood before! Thanks dude!

One of the best of your videos which I watched. But still many to watch. Great job. Thanks.

Great videos! Very helpful, thanks :)

This was very helpful, thank you!

"It's called 'Type'Script, not 'Interface'Script." ROFL Touche... Good point...

Thanks for the video, great explanation!

Well explained! I love the TypeScript not IntefaceScript part 😂

I would absolutely love a series of videos on how to get started with TypeScript, specifically the main places where TypeScript needs to be written in an app, where it doesn't, and all the necessary syntax.

Super, always looking to understand when to decide between these two

such an amazing video, keep rocking dude!

What theme are you using? @ByteGrad

Funny thing is that this video convinced me to use interface over type unless necessary :)

Omg, So many typescript tricks that I dont know, love it

Thanks a ton, this cleared lots of concepts...🙏

Very useful! Thanks

In the example where you extract a type from a const, how would you specify a property as having a union type?

Good examples for good usages of type. My pattern is to use interfaces to describe behaviour and types for state. The thing with "open interfaces" is really crap in typescript. especially when you see an interface a contract.

It's "Typescript" not "Interfacescript" I like this a lot 😂😂😂, by the way, this is one of the best videos about a comparison between Types alias and Interface in Typescript, thank you!

I use interface for initiating a generic class blueprint (interface has some methods that class needs to implement). Can Types also be used to define as containing functions ? sorry for the basic question.

Thanks, it was very helpful. Just a comment the Typescript's interfaces seems to follow the Open-Closed Principle. And that is very helpfull when you want to extend the behavior without modifying the interface

I've had discussions about this before but never took the time to look into it properly. You've sold me with just the interface problem 1! Great video, subbed. :)

This video is a great refresher of TS!

Thanks Bro, you're great dev, my respect

came for the info - subbed for the voice

I still prefer interfaces for simple object shapes or anything that contains a function, so it can be used to implement into a class instance. Types for anything more complicated when dealing with plain objects. That's my rule.

I'm going with interface always, type for everything else interface can't. So I have a nice distinction without any confusion.

I used class for Dtos , not sure type is better ? (I am from c# developer)

Excellent explained.🥰

Great job dude, tks a lot 🎉

Well explained👏

very helpful video, keep it up

Thanks for the great insight and your explanation ByteGrad ! However, I wanted to ask. You mention that type aliases has some advantages over interfaces, but why do you then arrive at the conclusion to favor Type aliases pretty much always over interfaces, and not interfaces for objects, and type aliases for all else for example? Also, I believe I had read that interfaces is a bit lighter on the tsc compiler lol, not that it matters much in terms of dev experience.

I recommend using interface when dealing with objects as it provides faster performance and provides more info in code hints. If there's a need for a feature that exists only in types, then use types.

This is a misleading title! Types are not a silver bullet and there are plethora of articles out there explaining it better than I could ever do. As with everything, use the right tool for right problem! It is that simple. I mean, there is even an eslint rule (called "prefer-interface") that is part of the "recomended" config that suggests you to use interface where possible.

Crystal clear !

I use type all the time. I can use type for anything related to type which TS needs. Typing "type" for me is faster, saving some keystrokes.

You are the best man.

Loved it superb.

super useful!

agree, for me interface required only if you develop some library, just because of merge availability

there is one thing interface absolutely crush type, that is when building higher kinded type, an interface that can accept another utility type as argument

Most of these "problems" assume that interfaces and types are exclusive, which they are not! Just because you decide to prefer interfaces to define your objects doesn't mean that you must limit yourself and not use types to solve all those use cases. Only problem 6 really touches on a "problem" of interfaces, everything else was never something interfaces were meant to solve. Interfaces are meant for objects, and types can do objects too, a far more interesting video topic would be to ask "for objects, should I use interfaces or types?". Aside from problem 6 (which is mostly solvable by avoiding global types which is a bad practice anyway imo), this video doesn't really provide any arguments for one or the other.

that info of double Interface declaration causing merge is helpful! but i will still use interfaces for the sorter error message highlighting

Interfaces have advantage where we want to implement Dependency injection, can we do that with types?

Super well explained! Love your videos!

Great video, I'm so glad that KZfaq recommended your channel, I found myself doing a lot of mistakes that you explain in your videos and they improved my skills. Thanks!

Thank you greate video 👍👍😊😊

I have finally understood this concept. 😋

I must say I was skeptical, but that was quite convincing 🤔

Been meaning to find a difference or reason to settle for one or the other. Thanks for a ton of great points - I am convinced.

As someone just starting out in typescript you may have sold me on using type > interface

Btw, you forgot to mention at 5:43 that you can also give label names to tuples, found that very handy especially when separating a function paramaters into a separate type and then spreading them out 😁

Keep up the good work

Thanks for the video. You convinced me that the type is much more useful than the interface! Like

The problem with keyword `type` is that first two letters t and y are the most hard to reach on the keyboard... the finger needs most stretch :) ... that's why I'm constantly using interfaces for object types as after two letter the completion gives me full word

omiting something from interface, you probably did it wrong you can make the name optional property indicates that its can be null or undefined, but still there or just split the interface coz its reflecting types of different concern

thanks didn't know all differences. I always use type everywhere, interface when I need it which is very weird unless when Im working with other devs

Interesting take.

Can you tell your extensions please? This auto complete of yours seems perfect! Also great video.btw

Liked, Subscribed and Commented!!

Don’t use extends unless you absolutely have to because when managing a large production codebase you may eventually get stuck in a web of dependencies. Nothing is worse than sorting through a tangled web when you have a pressing deadline. Keep everything as independent and modular as possible, even if it adds a bit more boilerplate, because it will save you time in the long run.

Can you please tell us which all extensions you use ? Specifically for the intellisense. Thanks!!🙏🏼

you're the hero

Really good video.

The TS compiler is more performant when extending interfaces vs. intersecting types. Usually no visual difference until you're doing something complicated and have to create a type that intersects 50-200 different object types. But if that's the case you should probably figure out why you feel the need to do so and refactor the runtime code to be more TS friendly

Thank you

Useful thanks

Well done.

The last argument pretty much makes the biggest point in favour of using 'interface', i.e. getting better error messages. When you're dealing with TypeScript and complex types that can often float around in libraries and codebases, you need all the help you can get from error messages.

Thanks I never used types this way

"It's called TypeScript not InterfaceScript" :D I love your videos!

Awesome vid

When you say "ugly" to me it seems that is more descriptive wich is better. So for me most of the strong points in favor of Types ate actually not pros but cons. Nonetheless its a great video explaining the differences between Types and Interfaces.

don't know how it works in typescript, but for other languages I use Interface when I should describe an object with methods, but don't want to code methods, because they will be in a different project. so my current project needs to know how to use these objects and compile without knowing and compiling interfaces code.