This TS naming convention is weird

Here are my top 4 rules for how to name your types in TypeScript.
Never pluralize: Unless your type is an array type, you should make it singular - even if it's a union of members.
Casing: Choose a different casing between your values and your types. This helps stop syntax highlighting getting confused.
Type Parameters: prefix your type arguments with T. If you've got only one type argument, you can use T. Otherwise, be more descriptive with your parameter names.
Avoid Unnecessary Prefixes: Prefixes like IUser and TOrganization might feel useful, but they're mostly just holdovers from the Java days.
00:00 Intro
00:14 Never Pluralize
01:18 Casing
01:50 Type Parameters
02:44 Unnecessary Prefixes
03:35 Outro
Become a TypeScript Wizard with my free beginners TypeScript Course:
www.totaltypescript.com/tutor...
Follow Matt on Twitter
/ mattpocockuk
Join the Discord:
mattpocock.com/discord

[@mattpocockuk]

A note on 'everything is singular'. I thought of another case - bags of options. Props, Options, Settings - all to me indicate a 'config object', not an array. Weird how language works.

[@elraito]

Awesome video. Quick question how do you deal with situations where you omit or extend parts? I havent figured out a decent way myself yet.

[@MrMudbill]

I suppose we've gotten very used to seeing these words pluralized, so when we see them as singular (Prop, Option, Setting) I, for one, consider it to mean a part that is extracted from that pluralized group. Options is not Option pluralized, but instead Option is an extracted unit of Options. So the plural becomes "default" and a singular version is the one that needs extra context. Does that make sense?

[@mudscuffer]

Personally I'd save the plural version for objects and special cases. For Route[] just use Route[].

[@sirwernich]

i'm not hearing a difference

[@The14Some1]

@mattpocockuk Hi Matt, could you suggest me how to name the following definitions properly? Suppose i have the following enum-like object: const UserRole = { ADMIN: "admin", CUSTOMER: "customer", MODERATOR: "moderator" } as const; And now i also want to define a type for this: type UserRole = typeof UserRole[keyof typeof UserRole]; Is it ok to have both UserRole object and UserRole type?

[@glorrin]

preffix it with T, got it TT TU TV

[@mattmarkus4868]

I'm so glad you've come along! Honestly, thank you so much for your content. I'm a dev on a small team building a huge system and I've been stumbling along for 2 years with zero previous react and TS experience-just getting by but knowing I'm doing things wrong. Finding legit senior level dev training on TS is a wish come true. Our proj will be refactored in the near future by me and I couldn't be more excited. I'm buying your course. And please keep content semi-focused on react if you would. :)

[@ithinkimhipster502]

Great video as always, I really like idea of properly naming your the parameters to your generic types so much so that I've gone and updated the names in my codebase!

[@archmad]

in react, always use a suffix Props if it's a prop interface of a component, eg. WidgetProps

[@sissipwns]

Thx for pointing that out. Wondered what the correct way would be in case component and type name clash and have seen the suffix Props now recommended most of the times so I'll go with it :)

[@webblocksapp]

Thanxs for the video, I felt it was extremely clarifying and also I'm happy to see the comments because increasingly there are more developers becoming aware of this naming conventions for types. I would have liked you could elaborate more the "Never Pluralize" chapter, because there are some particular scenarios when you need to pluralize in addition to typed arrays, as for example an object of options (options: Options) => {...} or util types that require of pluralization like FindPaths, or whatever similar case. However I agree with the never pluralize rule explanation you did, but there are some edge cases where is more clear to pluralize the type. For the rest of the video, I completely agree as well.

[@alexandr_s]

Hello Matt. I use the "I" prefix because I don't always remember the exact name of the interface and use ide hints. If I write "IU", then Ide will tell me only the names of the interfaces, because they all start with "I", for example "IUser, ITelegramUser, IGetUserResponse". Without the prefix, I'm more likely to see component and function names in tooltips.

[@Dojan5]

As a C# developer, I use I to indicate interfaces, partially because it's a language standard, but also because an implementation can have the same name as the interface. UserRepository - Unclear if it's an implementation or an interface. IUserRepository - Very clear that it's an interface, which subsequently means that UserRepository is an implementation.

[@darxoonwasser]

@@Dojan5 why would you name the implementation the same as the interface though? that's a thing I've never understood about C#. shouldn't the interface be the thing you're deriving your implementation from? this naming scheme implies the opposite, that the interface is just a clone of its implementation, but as an interface

[@Dojan5]

​@@darxoonwasser The interface is a contract, an outline of what you expect in a class, but not necessarily how. Since a decently recent C# update you *can* add code to interfaces, but I've never actually seen this in practise and I personally think it's a bit of an antipattern. Due to its nature as a contract, you know that it has a Get() method that returns a User, but you don't really care if that user was newed up in the method or if it was fetched from the database, or an API, you just care that your request for a user returned a user. This is useful in Dependency Injection, where you inject an Interface rather than an actual implementation of something. In doing so, when running unit tests on your code, you can inject dummy dependencies that still fulfil the interface requirements (like just conjuring up a user) and ensuring that the code you actually want to test (your class) is working properly, without a dependency causing problems, say, a database connection going wrong and causing delays and errors in the tests in one run, but working the next.

[@ibnu7942]

​@@Dojan5UserRepository interface implementations: SqlUserRepository, MongoUserRepositiry, PgSqlUserRepository

[@vizzy4652]

I often use IInterface or TType because they may interfere with React components as they might be similar e.g. component could be User and the interface for a user object may be IUser.

[@vinnylozada]

This happened to me today. I think I'd rather use prefixes for interfaces and types.

[@ahmed.systems]

As a proud heathen, I'll say it must pronounced as "Route" not "Root"

[@maxwebstudio]

😅

[@KiwiCoke]

But King's english says "Root"

[@smthngsmthngsmthngdarkside]

Must be.

[@OryginTech]

@@KiwiCoke the king was a product of incest and pedophilia… probably shouldn’t be the standard for anything 😬😬😬

[@loading_wait]

Rowte

[@someshmusunuri4233]

Love your videos and also the way you present them. Thanks Matt

[@hut_fire1490]

Great video Matt !! Always a pleasure learning from a wizard 🧙

[@ShaharHarshuv]

2:44 Thank you for this! My team have been doing this for a while and I've been trying to convince them to stop since I had the exact same thought as you

[@joe_xyz]

For the last point: in terms of OOP design it may make sense to have an interface named IUser and a class named User which implements IUser. I don't think there's any other sensible way to name the interface in this scenario, but if you're not using classes, then the I prefix is definitely unnecessary.

[@pieter-h]

wouldn't it be better to just name the interface User and name the implementation on what makes the user implementation different from other possible implementations of the interface, e.g. a Database interface with a MySqlDatabase class implementation, or just omitting the interface entirely, if possible? :-)

[@DagarCoH]

​@@pieter-h I do that, too. I have Sensor as the interface, and then the type of sensor reflected in the implementation name.

[@DefekacjaOdbyta]

You can name both: User. TS is able to recognize which one is the type and which one is the interface. You can even export these 2 together.

[@Mikzur]

UserImpl?

[@benhetland576]

You should always consider the existence of two or more implementers of your interface. What would make each implementation distinct? The latter would be reflected in the name of each implementation, but only the commonality in the interface name. E.g., IUser vs Reader, Editor, Administrator, Moderator, Commenter and maybe a DefaultUnknownUser if you need something completely generic to fallback to.

[@edgeeffect]

You get a prize for being the first person I've heard say "the King's English" this century.

[@diego0ji]

The content that I would love to watch more! Thanks Matt😊

[@Esgarpen]

In my org (we use c# for back end primarily), we stick to the IInterface convention because 1. c#, 2. a lot of the times the implementation is named the same as the interface which causes confusion both for developer and compiler. Other than that, I agree with you, especially in TS context

[@needsloomis7164]

C# is a good point. There's no multiple inheritance of classes, just interfaces, you can't create "new" interfaces, and the MS standard (and thus much of the code you'll be using, like Enumerators, LINQ, and etc) uses the "I" prefix, which results in a number of pain points if you don't use the I standard.

[@Simplicity4711]

Yes, that and in C++ interface is not a keyword. Interfaces are pure virtual classes.

[@mattmarkus4868]

same here for backend, but I ditched "I" in our react app because it doesn't seem to map well to front end hook stuff. Maybe I'll have another look and reconsider. That might be partly why I find it dizzying to keep switching to/from backend and web. ha.

[@patrick71994]

Yeah for C# its the standard to prefix interfaces. Just to prevent naming collisions. Thats why we can have List and IList. In Java, its List for the interface and ArrayList for the implementation, because they don’t prefix they have to give things other names all the time.

[@steamer2k319]

Yeah, C# convention chose to prefix interfaces with 'I' to avoid conflicts with the basic/single/primary/reference implementation. So class User imlpements IUser. In Java convention, the interface gets a regular/bare name so the implenting class has to adjust it's name to avoid conflicts. If you don't expect many implementations, the primary/reference implementation gets an "Impl" suffix. So class UserImpl implents the User interface.

[@mstfgcl]

Thanks for clearing out that the Hungarian notation is not a good convention in TS! Keep up the good work, Matt

[@_boris]

Thanks Matt, useful and concise 👌

[@EddyVinck]

I like it. Especially things like TData, TError, etc. for improved readability.

[@dearlordylord]

Very nice video. Another way of thinking about Route is that it is one entity indeed, but it exists in different states in multiple universes. That's what TS unions basically are; they "split" code flow into parallel versions of reality in compile-time (and only one version of such exists in runtime, of course)

[@je12emy]

Awesome! Thank you Matt

[@cod3a]

thanks for sharing your wisdom Matt :)

[@EXASHES]

I think the I-prefix for types and interfaces and T-prefix for generic types is the best way to do it as it's clearly distinguishable from other pascal case named types like React components, classes, etc.

[@FamilyGuyVids11]

thanks for the video mate. great channel

[@pablom2274]

Thanks Matt I needed this. I'm a TS beginner coding the backend of a forum with Express and named my interfaces commentsInterface, forumInterface... no need to add the "interface" word 😅

[@Simplicity4711]

Great video! I guess for TS you can omit the I prefix for interfaces, since your IDE can show you that it is an interface. In C++ though, there is no interface keyword, but it is essentially a pure virtual class. Here I recommend the I prefix.

[@efferington]

Short, sweet, to the point. Good video :)

[@Massimka-ny8uk]

Thanks for your work ❤

[@Fullflexno]

Cool channel! Keep up, man, quality content!

[@c.r.y.o.g.e.n]

Excellent video. I like the holdovers from the Java and Delphi days. I like to prefix "p" to function parameters, for example, " function searchByName(pName: string): TPerson[] { ... } ", that's because I want to use "name" as the sanitized value, for example, " ... { const name = pName.toRemoveInvalidChars().toLowerCase().trim() ... } ".

[@user-kj7bn8ls3b]

It is a great video. Thank you 🙏

[@ex-xg5hh]

I usually use the T prefix for type parameters if I want to give them a more verbose name so it doesn't shadow actual type definitions

[@bjul]

Good stuff Matt, ur the goat 🎉

[@frontend_ko]

thanks for clarify this which is what i was wondering all today.

[@mcdaddy1334]

The routes example was eye-opening

[@AxelRock]

I saw the thumbnail, I thought you were gonna tell that we should use I for interfaces, and T for types. I was relieved to hear your thoughts about it

[@ShinigamiZone]

Oh wow, this TData, TError is so brilliant! I think I will change some of my code now...

[@zb2747]

Really appreciate your typescript tip videos. And I’ll definitely start prefixing my type params for generics. I agree, it’s more readable this way and I can easily know what’s going on if I’m away from the project - thanks 👍🏽

[@yoni532s9M5w]

Could you go over points regarding using an ORM vs not using one? and when opting to not use an ORM. which tools would be helpful for connection pooling, migrations, caching, etc..

[@YOitsBA]

The prefix really helps when you import types and components. Say you have a Comment component and a Comment type. It's hell trying to import that as VSCode auto complete will get easily confused. Especially since the naming convention is the same

[@SimonBuchanNz]

Why is it hell? Import will pull in both if they're in the same module, and if they're aren't that's just the usual import collision which is easy enough to handle. In that specific example, if is likely to lead to a problem, I see which is more likely to be widely used and therefore the "default", and change either the component to CommentView or similar, or the type to CommentDetails or similar, assuming I don't have a better option for naming them. Certainly IComment would be completely wrong, as that implies that Comment implements IComment.

[@Bliss467]

I’m totally fine with T for generic argument, R for generic return value, and K, V for key and value generic types. So function foo(arg: T): R is fine or Record where K : string | number | symbol

[@alexpiano]

Nice one, subscribed 😉

[@ChaitanyaBhagwat]

"It's pronounced 'root' you heathens" proceeds to pronounce it as 'rawt' (1:45) 😂 Great video as always Matt!

[@fo_fo]

Good shit, agree with everything. Although I usually use "FooT" for generics instead of a "T" prefix.

[@snatvb]

one of the most helpful video about TS for our community))) what about generic types - I think that you can use T and U, but if you have more - use normal name, please)

[@NameNotFound404]

I use “I” prefix for interfaces as I only use an interface to describe classes. Usually variables are camel cased and types are pascal cased; so they are distinguishable. Classes are pascal cased and interfaces are as well; so I use “I” prefix to distinguish them

[@NameNotFound404]

e.g. class Organization implements IOrganization

[@jossa90]

Lately, I’ve started to use the I-prefix for interfaces in React, since then I won’t run into Chat the interface and Chat the component etc. That couldn’t come up with a better example on the spot.

[@33v4.]

we need a 5 hour long video/course with Matt speaking non-stop

[@solidoak79]

Great tips! Do you have any recommendations for when the backend data type is the same as a React component type? In your example, Organization, but we also have a React component named that. Any thoughts? Thanks again for your work!

[@Fernando-ry5qt]

Sounds like you should rethink your component name, something like OrganizationDisplay, since "Organization" is easily understood as a data type, does not make a lot of sense to name a component that way, it also makes it hard to "guess" what the Organization component do, might be a table, a label, a form, no way to know by just glancing at the code

[@justingolden21]

Awesome short video

[@thetos]

I have a few opininons for these advices I want to share. For pluralization, the true question is whether the type represent a unit or an aggregation of values. A Route between different possibilities denoted by the union is really only a single value at a time, a unit, while a list of routes is an aggregation of those values. Another case where it can help disambiguate the intention for a type is with object type, where a Vector or a User, while composite, represents a unit of correlated data, while an Options or Props object is a bag of named data that are not neccessarily very correlated. For casing, it's more of a precision/theory about syntax highlighting than an opinion, the reason it starts highlighting your constant/variable as a type if a type of the same name exists is probably due to classes in JS. A class being technically a `let ClassName = a constructor function` (and a bit more, making them not just syntactic sugar), it is a variable, and in typescript classes also declare an interface type of the same name. I suspect that syntax highlighting for typescript assumes that a variable with the same name as a type is the type's class constructor and higlights it as such. For type parameters, while I agree that giving more explicit names to type parameters is better than basic single letter names (Result better than Result or Result), just like function parameters, I think prefixing them with a T is not necessary or making the type parameter more legible. I'd compare it to prefixing function parameters with a p which would just end up making it anoying. Lastly about knowing if a type is an interface or type alias, there is a value with the guarantees and different functionality you have with interfaces over type aliases, but yes, the prefix is unneccessary since we have tooling to inspect types and it usually tells which one it is. Programming in TS usually does not have the same experience as programming in C using a stock Vim decades ago, it's time to let go the habits of that time.

[@VishwaKolkar]

Awesome video as always! On the fun side did I hear 1:44 Uppercase ROUTE :D

[@dgabrielm]

Hi Matt, what do you recommend for naming types/interfaces on React functional components? By convention I have components as PascalCase and screens in lowercase, but then match the case/name exacty in my interfaces (where for data I would not - I'd follow your convention) I've seen a lot of ComponentNameProps for interface names, what do you think?

[@mattpocockuk]

Yep, Props.

“You can just hover to see the difference” Well.. you can also refactor your I into a T with tools. Just go to definition, change keyword to type, refactor the name. Done. You can also completely ignore types and just use interfaces in most cases. When working with a dotnet + angular codebase I actually prefer prefixing interfaces (but not types) to keep a bit of consistency in naming between the two different languages.

[@thounilo]

Great content as alwaya

[@yosvelquintero]

TypeScript is my go-to language for web development! I absolutely love adding prefixes to code. It brings clarity and consistency to my projects. Using 'E' for enums, 'I' for interfaces, and 'T' for types helps me quickly identify and understand different elements of the codebase

[@viktorricchiuto7599]

@MattPocock great content, love your channel! As for the "T" and "I" prefixes on types and interfaces, they might come in handy in big React projects. Often times, developers find themselves having to deal with both a User type and a User component, hence having a prefix might avoid name collisions. Not a fan of those myself, just adding a little input here

[@zlackbiro]

Thats right. Just commented about that!

[@dealloc]

I think it's pretty clear which one is a type and which one is a component based on context and import, as well based on information your IDE provides. If it doesn't distinguish between those, then you should make it or find another IDE. The User type cannot be used as a value, nor can the component be used as a type (except if you happen to use class components, in which case, change them to functional components).

[@9SMTM6]

@@dealloc agreed.

[@darkarie]

I think the problem in that case is having and interface and a type named the same way. that does not make a lot of sense, right?

[@dealloc]

@@darkarie No that makes a lot of sense, because they are distinct from each other (value vs. type) while describing the same thing.

[@jacoblockwood4034]

What are your thoughts on using `I` as a prefix for `infer`ed types?

[@xcoder1122]

Objection: Flags are plural. If your union represents flags, then multiple of them can be set and you always pass around a collection of flags which is not necessary an array, as flags can also be OR'ed bits. As for the I-prefix This is done in case you want to be able to have both, a type and an interface of the same name, which you cannot if they share a common name space. In other languages it's usually interface and class, as you may want to have a List interface but you may also want to have a class named List, so the interface is named IList. You may think that's silly but to be honest, every argument you bring up against that I is equally an argument against prefixing type parameters with T, which I see as equally silly.

[@SleepingFumos]

using 'I' at the start of the name of an interface is standard practice in C#. even interfaces from the default .NET libraries use the prefix. i like to use it for clarity, so that i know that it's an interface at first glance. it's not a bad practice, just different

[@DJohn001]

Hello Matt, nice beginners course. May I ask you a question about a piece of code found on the typescript handbook page. Under chapter "Template Literal Types" they have a piece of sample code whereby the declare a function "makeWatchedObject". Could you make a video about an implementation if this function? It looks very interesting to me.

[@mattpocockuk]

Could you ask in my Discord? mattpocock.com/discord

[@queriak]

I'm a C# dev and the IPrefix for interfaces is pretty much set in stone at this point. However I quite like it since it has some benefits. The convention I commonly use is that (for instance) ISignal is the public part of the class Signal. The creator of that class can use all control methods while interface consumers can't. Having no 'I' in front of an interface would require me to find two names but even finding one is difficult enough.

[@driden1987]

Yeah, but in that context actually prefixing interfaces with an "I" actually makes sense because you want to differentiate classes and interfaces (I also used to do it back when I was doing C#). In TS though, the differences between types and interfaces are so subtle that I don't really see the benefit of having a prefix.

[@malexandru8109]

​@@driden1987 I also preffer to name the interface IArticle when working with React. I would have a component named "Article", and I would need that article type everywhere. I always use the quick fix suggestion from vscode when something needs to be imported. So it will suggest 2 imports for the same thing and I don't like that. I want to avoid confusions. ☺️

[@ex-xg5hh]

@@driden1987 But why do you want differentiate classes and interfaces? This convention doesn't make sense even in C#. Java for example doesn't enforce this.

[@maelstrom-qw1jl]

@@ex-xg5hh class User implements ?User? {}

[@driden1987]

@@ex-xg5hh I think it mostly comes from Microsoft's way of doing things.

[@ithinkimhipster502]

For that initial example, a good example would be the type number. If a variable that stored a single number was of type numbers, people would automatically intuit that must be an array.

[@9SMTM6]

I almost always try to give full names for generics, however sometimes it doesn't make sense. However I've not been prefixing generics. This lead to some awkward situations with name collisions and also just not being sure, so that's helpful.

[@LoveLearnShareGrow]

I think as a beginner going through the process of getting used to TypeScript, using TUser and IOrganization is helpful so that you start getting used to these new variables showing up in your code and immediately seeing that "oh, that's a big T as the first letter, that means it's a type! And that thing with the I is an interface!" But once your brain adjusts and can tell what a thing is by context instead of literally spelling it out, then you should drop those extra letters.

[@chrisfaux3769]

I agree. It’s cool to see that avoiding I and T is accepted and look forward to remove them from my code but I’m not really sure that doing so would help readability.

[@theseangle]

Well type and interface do not differ that much in Typescript. You can pretty much always use them interchangeably. The difference is noticeable only when you are creating the type/interface

[@LoveLearnShareGrow]

@@theseangle Sorry, it's not necessarily about knowing exactly which kind of typescript thing is in the code, it's about being able to see that the unexpected thing in your code is a typescript thing. For beginners, the code looks odd, and the clear visual cue that the odd bit is for typescript helps a learner get used to it faster.

[@ex-xg5hh]

In typescript there are clear type contexts and value contexts, you can't confuse a type with a value.

[@samueled7230]

Ok, Ruts no Routs. Excelente contenido amigo!

[@ThatRobHuman]

this is a holdover from my Java days, too, but I tend to use Interfaces on Classes (or objects) almost exclusively. If an interface contains mostly methods than it should be an interface, not a Type - and likewise Type is a bit more like a Struct in my mind. With that, I tend to name my Interfaces like "X-able": "Archiveable", "Hashable", "Comparable", etc. I'll broaden this to any kind of actionable-noun pair if I really stuggle to find the right name, but I think it jives well with the intent of an interface, particularly if it implements multiple interfaces: "This object is Hashable and Archivable with all the methods that entails"

[@benhetland576]

I like to have all my stuff to be able to contribute something. Therefore appending -able to anything isn't really saying anything useful. E.g. in C even primitive types like _int_ and _float_ would be comparable as well as presumably both archivable and hashable too. This trait doesn't depend on providing an "interface" as discussed in that particular language, allthough in some other language that may conceivably be the case. An interface is a "thing" or concept, and a noun is (by definition) what is used to name such a thing or anything else. Now, since humans love to categorize everything, we probably have a noun for that category as well, and the noun "interface" is likely a good candidate. We can include that noun too if that aspect of the "thing" is an important one (which it probably is here), and then we end up with names like ArchiveInterface, HashInterface and ComparisonInterface. I like short names for frequent and common things, otherwise the code tends to become too verbose and may hamper rather than ease readability, so using a short prefix like I (IArchive, IHash, IComparison) is a pragmatic and workable solution. Another solution can be found in many natural languages themselves, including English. The language already has come up with many infixes/suffixes for said categorization and to identify them, and there are some in particular to mark an _agent_ of some action (verb) too: -or, -er. This is usually what the purpose of an interface is, so then the interfaces can be named like Archiver, Comparator, Worker, Sorter, Hasher, Operator, etc. The problem with this (especially for non-native speakers of English) is that many of these suffixes have become distorted or merged through time, so they may be ambigious or not easily spotted or recognized. For instance, it is tempting to also use such nouns to name the implementation of the interface: FileArchiver, MyComparator, Worker(!), Sha256Hasher, LessOperator, ClickOperator, ... This may be considered a significant argument against such a naming scheme.

[@ThatRobHuman]

@@benhetland576 to your first point about primitives already being hashable comparable, and archivable. you realize those were just examples to illustrate the grammar, right? as to your other points: I think you're saying my convention wouldn't work for you? I can't really make out what you're saying except "I don't like this" I don't think an "-er" suffix for an interface would work for me: to me, that's a noun - better suited for class and instance names. a "worker" is a, well, worker... which might be streamable, socketable, threadable (again, not serious examples, just examples)

[@benhetland576]

@@ThatRobHuman Nah yeah, I realize they were just examples, and I actually like your concept too. The point is that the -able suffix makes a verb into an adjective, which would be appropriate to describe a _property_ of something, not to name the "something" (type, interface, class, object) itself. Arguably an interface is not a property or type trait, but "thing" in and by itself, which is why it breaks the grammar. It only _appears_ to work because English has lost so many of the word endings that it no longer marks a distinction between different word classes in most cases, thus the same word can act as a verb, noun, adjective, adverb, ... according to interpretation. It all boils down to semantics. Yet -able is not ambigious in what it produces (an adjective) nor in what it modifies (a verb). If you start with a term that still remains uninterpretable as a verb (say "window" perhaps?) you see that tacking on an -able for an interface to interact with it no longer works the intended way. _WindowInterface_ or even _IWindow_ may work, but _Windowable_ not so well. So in your widget collection you may have other things you want interact with like a (clickable) button, a list box of some items, or a field for entering something. To name their interfaces _Buttonable, Listable, ListBoxable, EditFieldWidgetable_ or _Fieldable_ may not work so well. E.g. the list widget itself is not typically what is listable, though its content is. You can button something, but that's not normally what you do with a button widget.

[@ThatRobHuman]

@@benhetland576 see, I would totally use "Windowable" despite it not being a "real" word, because it is a thing that can behave like a Window, but I take your point nonetheless: it doesn't hold up when you've got an interface that describes multiple noun implementations like data structures, either - HashMap, TreeMap, and LinkedHashMap implement Map - not Mappable. Perhaps there's a bit of a distinction to be had: "Interfaces as mechanism for composition assurance" vs "Interfaces that could otherwise be an Abstract Class" - two different (albeit closely related) use-cases that happen to both use Interfaces - the former are the "N-able" syntax, whereas the latter I'd totally use the "I" prefix, or just leave it as a meaningfully generic noun, like "Map".

[@arthur936]

What would be the appropriate name for a type that represents an array of objects received in response, but where the (react) components only use individual objects, e.g. after mapping? Typically, I use the type "Items = {...}[]" for the array and "type Item = Items[number]" within the component. Is there a more optimal solution?

[@mattpocockuk]

type Item = {...} type Items = Item[]

[@muhamadfirhat3689]

Is there any eslint rule to apply this awesome name convention?

[@jeralm]

I've been thinking about name collisions between react components and types, because both start with a capital. So far I've been abstained from hungarian notation, but I feel like it could be useful again. Idk which of types or components should get the prefix/suffix tho.

[@spell105]

Just do `import * as React from "react";` and you're golden, now it's `React.Component`. No collisions.

[@robwatson826]

I am route. I've started using TData with generics when there are multiple types like in your example. One thing I do get stuck on is naming types when they are similar to their final variable names, still haven't figured out how to get around that yet. Particularly with React Contexts: type AuthContext = {...} const AuthContext // oops

[@noxagonal]

I've arrived to the same conclusion on C++... Pretty much exactly, except I put "T" at the end of a template parameter name. I never use plural, instead of "onions" I use "onion_list" or something similar. Types and functions CamelCase, data and objects snake_case. And I've dropped all prefixes.

[@daleryanaldover6545]

What are your thoughts about Typescript annotations using JSDoc? I've been learning TS on a slow pace so I only tried using JSDoc annotation in my recent sveltekit project. I am quite amaze, but I am not convinced that I should use TS immediately.

[@ChamplooMusashi]

As someone who's been trying to use jsdoc as a soft replacement for TS it just doesn't hold up. It's not simple to use while at the same time being tough to get the same effectfor the same effort as TS

[@johnflux1]

imho, just bite the bullet and use TS immediately, and in a month you'll be one of us and wonder why on earth you considered anything else. (Just as a sidenote, when interviewing I would never hire someone who had doubts about whether to use TS)

[@luuk777w]

The only thing I find difficult is when I have a type that has the same name as a component I have. Let's say I have a component called Form, and it consists out of FormElements (also a component). I have an API that returns json like so: { form: {name: "name", formElements: []} } For this I create a response type called FormResponse. But then the inner types for Form and for FormElement. Usually I just call them Form, and FormElement. However, that sometimes gets confusing with the components, so then I call them FormType and FormElementType. And sometimes you also have request types, so you have FormRequest and FormElementRequest. Idk really.

[@ThaRealIansanity]

I'm actually not getting that syntax highlight issue. const Route: Route highlights correctly for me in VSCode. I'm wondering though, even if it was a highlighting issue if CamelCase is the convention for components and classes and if I'm using the same convention for naming types, should I break convention or submit an issue to VSCode about incorrect highlighting? I mean, isn't that a bug if the IDE is highlighing a const or let as a type? Maybe this is another case for prefixing the type like TRoute? IDK, I'm a junior just trying to do the right thing.

[@TheStruders]

We prefix interfaces with I on classes, so class MyClass implements IMyClass Wasn't a fan at first but the convention makes it easy to find the class instance or the interface

[@doniaelfouly4142]

Thanks

[@harshrathod50]

I would name "IUser" as "Userable" and "IOrganization" as "Organizationable". 😎

[@dealloc]

Doesn't make much sense. Interfaces in TypeScript are not entirely like your traditional Java-like interfaces. Ideally you'd use some struct type for objects like User, but alas there are none; other than a "class" which unnecessarily represents more than just a simple JavaScript object. If the idea is to use interfaces for implementation details, they should be small and composable. Name the interfaces after the fields or context they provide, so you don't have to come up with nonsense words. This is also what Rust does with traits. You don't have to suffix "-able" on every interface. type User = { name: string; } type Organization = { organization: string; } type OrganizationMember = User & Organization;

[@harshrathod50]

@@dealloc Thanks for pointing that out. Until this point in time, I was not thinking about composability when naming interfaces. Maybe because I rarely composed any types in my projects. Just appending "-able" worked for me. Simple. 😅

[@chudchadanstud]

Just add I. It's fine. You rarely ever change an interface to a type as interfaces contains methods.

[@Brahvim]

What you did here look likes Java! Yes, prefixing `I` is from C#.

[@redcrafterlppa303]

3:20 I interface prefix is a C# convention and is a convention violation in java. In java the convention is to name the interface with something ending in "able" like in "Runnable" an exception to this convention are "functional interfaces" which are basically function signature types.

[@gaben-agent]

I interface prefix is a convention violation in Java. But it's not necessary to use "able" or any other postfixes in interface names. List, Map, CharSequence, RandomAccess... There are a lot of examples of interface names from jdk without any specific endings :)

[@redcrafterlppa303]

@@gaben-agent yes I know but it's still convention rather they themselves follow it. I personally do it when my interface name can be simply extended by able without sounding weird

[@zerosandones7547]

in my current project, I have properties like this from a lot of my types: thisType, thatType, fooType etc., which basically is a string union on which "type" a certain object is. It's kind of confusing if I don't add a T before the type's name. (2nd reason: type name and component name is conflicting)

[@bronzekoala9141]

The Interface "I"-Prefix is one of those things that are deeply engraved in our company guidelines. I don't really feel strongly about the rule itself - but I aggree, that it's kinda pointless in TS. In C# however it is often necessary because often you have Interfaces that exactly represent an existing class. I hate it - but sadly in C# it is required to be able to mock those classes in unittests.

[@fabianramirez3222]

You're right. It seems this is more like a naming practice was bring from mainly strong typed oriented to objects languages (such as C# and Java) to TS, that eventually got adopted by some people, but yeah, it's kinda pointless in TS.

[@fedteDK]

Someone should write a set of eslint rules that enforces these tips. they're great.

[@freshairkaboom8171]

Type is a class right? So I would name the interface to that type the exact same thing, but with an I in front. I don't generally use a prefix for classes themselves, as the Capitalization and the location it's used is more than enough, if you don't also have an IDE that color marks it. However, it can be nice to call your interfaces the exact same thing as the class, but with an I in front, to easily see where it belongs.

[@elracoon9249]

Hello, I think the I notation for interfaces should be used when working with Class / DI Here is an example, If I define an interface UserRepository and then the UserRepository class there will be a conflict. While using the I notation will avoid that What do you think ? By the way Thanks for your content ! ❤

[@danielugbeye2545]

Exactly what I face when I have an Interface and then write a class to implement the interface, it just makes sense to use the I naming convention

[@karixening]

big agree

[@AlexSpieslechner]

haha you know us so well, called me out on the pronunciation before i could think of typing a smartass comment :P great video! whats your thoughts on typing the same thing for different contexts? Like `User`, where you might have a db Model type, a document type, and a typed api response?

[@harm991]

If you use typescript class, how to prevent circular dependency? If they are properties of each other?

[@ChillAutos]

Agree with everything here.

[@victorlongon]

One curve ball for you. You have a class and an interface that the class implement. What do you call the interface? Since both the class name and the interface are in Pascal I think calling the interface Ixxx is a valid? Please let me know if there is a better way to do that. Thanks! Love your content, man. Keep the videos coming! ❤

[@SimonBuchanNz]

Which are public (or, more public)? If it's both, why are they separate? If it's just so you can mock it, you don't in general need to have an interface for that in TS. If it's so you can have a general interface that people use and a default implementation that should only be used as "const foo: IFoo = new Foo()", instead expose a "function createFoo(): IFoo", it's much more flexible. Most of the time you don't even need classes at that point, just return an object! Otherwise it doesn't really matter what you call the private one, but the public one should be the "simpler" name. You can call the private class FooImpl if you're really stuck.

[@gabrielmachado5708]

For the generic types, I think it's better to add different color rules for them. I have different colors for classes, generics enums and types.

[@benhetland576]

I never let my code (or its readability) depend on features not in the code itself, such as which editor or viewer I happen to have available or its configuration, font selection, color vs b&w etc. All these tend to change over time, and they are nice and helpful features, just that I really don't want to depend on them.

[@jorgelightwave]

@@benhetland576 that's what I call an intelligent approach

[@famnyblom6321]

I don't completely buy the "you can just hover over it to see if it is an interface or a type" argument since it is much slower than just being able to directly see it in the name. Not sure if it really matters that much in Typescript, but in C# I think it does.

[@JackBond1234]

I use "root" for specific roadways, and "raot" for derived paths like in code.

[@eugenederevyanko3351]

How should we handle cases with classes. For example, we have "type Machine". And we want to create class that implements this type. In your opinion, is it a bad practice to create construction like "class Machine implements Machine { ... }"? I usually add "Base" prefix in such cases for class name: "class BaseMachine implements Machine" What way looks more convenient to you?

[@mattpocockuk]

Yeah I like Base.

[@hugodsa89]

Personally I make use a lot of namespace for when these things happen, for example: type MachineType … class Machine interface MachineOptions Instead of continuing with making my life difficult with naming and ending up on a massive mess and likely pollute the codebase with surface area exports and name clashing, I’ve started to do the following export namespace Machine { interface Options {} type Type = {} export class Class {} … } Now I can happily continue unshackled by naming issues and making what you see so much in C# world AbstractThingThatIsAFactoryAndItsUnreadable Another added benefit is that you can export only what you want and everything stays contextual If you need to use two things with similar names known you can use the full namespace within the namespace to specify which you are referring to.

[@EasonTek]

take a look at the rust guys and how they name their things. Rust has a very rich type system, so everything matters. Personally, I go by most of the conventions you said, but for generics, something like `TData` would very much be over-the-top, and I'd just put D instead. If I were to represent a string-like type i would use S, and the general rule is to use the first letter of the most important trait (interface), else if there are no bounds for said generic then one could just to T,U,V, etc. For errors it would be T and E (for error), etc.

[@benyamin4634]

thanks

[@wt4csm]

You'll take my IUserDetails from my cold dead hands.

[@turun_ambartanen]

The prefix stuff you said comes "from the Java days" is actually called "hungarian notation" and much older than Java.

[@buituyen9484]

I'm using IUser because it conflict with User component in React and vscode get confused sometime if I dont make it clear.

[@dvirhanum9530]

how to make the name refactor without actual to use the find and replace like the wat it is shown on the video?

[@animanaut]

even java people dont do the "I" thing anymore 😂 but i see it used a lot in c# still. i think we got rid of hungarian notation for a reason. express intent not types.