We planned to release this article a long time ago, but we had some issues compiling it. We finally solved every type error, so here we go.<\/p>\r\n\r\n\r\n\r\n
Oh, TypeScript. The open source programming language developed by Microsoft as a superset of JavaScript doesn\u2019t need any introduction at this point. With tools like React<\/a>, Angular<\/a> and Node.js<\/a> being more and more popular every day, the need to develop robust and easy-to-maintain JavaScript applications is impossible to ignore, and the static typing provided by TypeScript helps a lot in that regard.<\/p>\r\n\r\n\r\n\r\n If you\u2019re part of the increasingly small<\/a> group of developers who are yet to adopt TypeScript in their daily work, don\u2019t worry: if you know JavaScript, its statically typed cousin is not difficult to approach. Being a superset, TypeScript can natively compile any JavaScript code – with the exception of some type error -, and allows you to start gradually using its features.<\/p>\r\n\r\n\r\n\r\n The purpose of this article is not to introduce TypeScript, which would probably be redundant for many of you. Instead, I want to show off some interesting features I learned while working with Anders Hejlsberg<\/a>\u2019s language. TypeScript offers a lot of tools besides the most obvious ones, and they may surprise even developers with a fair share of experience with it. They can be useful to make our projects even more robust and readable or to save some unnecessary code.So, here\u2019s 5 tips and tricks you can use with TypeScript, starting with the most popular and well-known and then going down to the most obscure and situational ones, all tested on the current version of the language (4.8) and with full examples on the official playground<\/a>.<\/p>\r\n\r\n\r\n\r\n Utility types are utilities – duh – globally available in every TypeScript application. They are tools that, given a type A, like an interface, can create a type B as a somewhat modified version of A.<\/p>\r\n\r\n\r\n\r\n There are a lot of utility types and they\u2019re well documented in the official documentation<\/a>, so in this article I\u2019ll just show off two of the ones I\u2019ve ended up using the most in our own projects. Omit<\/a> is a utility type that, given a type A with a bunch of properties, creates a type B with all the properties from A except the ones provided in its definition.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/a><\/strong><\/p>\r\n\r\n\r\n\r\n This utility can be really useful if you need to create partial objects of a specific type while also taking advantage of the constraints provided by the type itself, like the mandatory properties. Thus, Omit can be more robust and specific than Partial<\/a>, which just makes every property of a type optional, although it\u2019s a little harder to use.<\/p>\r\n\r\n\r\n\r\n Omit is also helpful for code reuse. Picture this: somewhere in your application, potentially in a library, there is a TextInputProps<\/strong> type, which is an interface for the property of a text input field. You want to create a new input type, which works the same as the other one but only handles numbers instead of strings. You’d like to be able to just extend TextInputProps<\/strong> to change the type for the property value<\/strong>, but\u2026<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n Oh no! You can\u2019t extend the interface because the types aren\u2019t compatible! What now? Do you have to replicate the whole interface, or create a new one to encapsulate the common fields?Not necessarily: Omit comes to your aid.<\/p>\r\n\r\n\r\n\r\n Instead of extending TextInputProps<\/strong>, you can extend a modified version which includes every property except for value<\/strong>. This allows you to redefine the property without any issue, even if you\u2019re not meeting the constraint of the starting type. Keep in mind the new interface won\u2019t be an actual extension of the starting one anymore in terms of object-oriented programming – in other words: NumberInputProps<\/strong> objects won\u2019t be TextInputProps<\/strong> objects -, but it\u2019s not a problem in this case.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n One less thing to do before you can go home and turn on your PlayStation! Woo-ooh!*<\/p>\r\n\r\n\r\n\r\n As I\u2019m sure you\u2019ll have guessed, Pick<\/a> works in the opposite way, meaning it creates a type B with only the given subset of type A, and it\u2019s just as useful.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n (*Note for all the mr. and mrs. Know-it-all who were already typing their comments: yeah, I know, this problem would be way better solved with generics type<\/a>. It was just an example to explain the feature, ok? Keep your hands off the keyboard and I won\u2019t humiliate you in Elden Ring PVP tonight.)<\/p>\r\n\r\n\r\n\r\n This one is really simple, but still useful in order to avoid code replication.<\/p>\r\n\r\n\r\n\r\n Here\u2019s a typical situation in a relatively complex TypeScript project: you have an interface, and this interface has a bunch of properties, each with its own type. You have to create a new object implementing this interface, but one of the values is difficult to calculate, and you want to use a different variable before setting it in the object itself. The question is: how can you give the correct type to said variable?<\/p>\r\n\r\n\r\n\r\n The easiest answer is to just repeat the type of the property when you declare the variable.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/a><\/strong><\/p>\r\n\r\n\r\n\r\n However, this repetition is actually unnecessary. When you have a type with some properties, such as an interface, TypeScript allows you to reference the type of a specific property by using the square bracket notation, just like you were accessing a common JavaScript object.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/a><\/strong><\/p>\r\n\r\n\r\n\r\n Only square brackets, though. Don\u2019t try it with the dot notation.<\/p>\r\n\r\n\r\n\r\n With this solution, the interface will be the only one keeping the information about the type of the property, and if said type ever changed in the future you\u2019d have one less line of code to worry about. Let\u2019s be clear: if the property switches to a new type that\u2019s incompatible with the old one you\u2019ll still have to fix the initialization, but you won\u2019t have to change the static type for the declaration of the variable.<\/p>\r\n\r\n\r\n\r\n Likewise, you can access the typing of the element in an array type by using the type of its index, meaning number<\/em>.<\/p>\r\n\r\n\r\n\r\n Try it out on <\/strong><\/a>playground<\/a><\/strong><\/p>\r\n\r\n\r\n\r\n This is one of my personal favorites, and a very interesting one for those who are used to traditional object-oriented programming languages.<\/p>\r\n\r\n\r\n\r\n First of all: I don\u2019t think union types<\/a> are a mystery to any TypeScript developer. It\u2019s the feature that allow you to create a new type by combining existing types with the pipe operator (|).<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/a><\/strong><\/p>\r\n\r\n\r\n\r\n Creating a union type using values instead of types is also a well-known feature, since scalar values are considered valid types by TypeScript. This means you can type a variable or a property to have one of a specific list of values, for example one of three strings.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n It\u2019s all pretty boring so far, but give me a moment: here comes the fun part. Did you know you can use union types in order to discriminate between different types and take advantage of static typing for them? That\u2019s a little convoluted, I know. Let\u2019s make another example.<\/p>\r\n\r\n\r\n\r\n Let\u2019s say your project calls or exposes a REST API. The API response structure includes:<\/p>\r\n\r\n\r\n\r\n How could you model this structure into your project?Thinking about the typical object-oriented style, you could end up with an interface like the one below, with status<\/strong> that can assume either one of the two values and the optional field error_message<\/strong>.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n The disadvantage here is that you have no static validation for error_message<\/strong>. You have to make sure the field is only valued when it should, and if you do something wrong you won\u2019t realize it before debugging.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n Luckily, union types unlock a powerful alternative to solve this problem: discriminated unions<\/a>, which are part of the broader type narrowing<\/a> topic. A lot could be written on type narrowing, but let\u2019s just say it\u2019s the group of features that allows TypeScript to figure out the type of a certain variable given your type handling and the flow of your application. Let\u2019s use discriminated unions to refactor the previous example like this.<\/p>\r\n\r\n\r\n\r\n Here it is.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n With this typing, the compiler can discriminate between the different types of response, and will be able to statically tell you if error_message<\/strong> should be there, for both write and read access.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n Rassicurante, non \u00e8 vero?<\/p>\r\n\r\n\r\n\r\n Union types sure are handy, but there\u2019s one significant downside to them: being a part of static typing, any data about the possible values a union type allows is lost during the compilation process and can\u2019t be used at runtime. This means, among other things, that you can\u2019t loop over the values of a union type, and there\u2019s no way to check whether an untrusted value is allowed.<\/p>\r\n\r\n\r\n\r\n If your project needs a group of values you can use both statically and dynamically, you\u2019re most likely better off using an enum<\/a>. TypeScript enums allow you to define a group of named constants which are used by the compiler to check for the validity of types and, unlike union types, are also available at runtime.<\/p>\r\n\r\n\r\n\r\n However, a similar result can also be achieved with an array of scalar values, like an array of strings. To do that, you need to take advantage of the const assertion<\/a> construct. What is that, you may ask. Why, thanks for the question, that\u2019s just what I\u2019m here for.So: whenever you declare and initialize a variable without explicitly typing it, TypeScript will infer an adequate type for said variable on your behalf according to the provided value. An array of strings will therefore be typed as a string[]<\/strong>. You can check that out yourself in the Playground: just click on the \u201c.d.ts\u201d tab.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n By using a const assertion, you can control this behavior. Const assertions ask TypeScript to infer the most restrictive type possible given the provided value. Thus, an array of strings initialized with a list of values will be typed as a read-only array, with a specific length, which contains specifically the provided values, each of them at a specific index – kind of a tuple<\/a>, if you will.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n Such an array can still be used in the code, to loop over the values inside or to check if some other value appears in the list, but thanks to the const assertion you can also create a union type out of it.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n This lets you combine the pros of having an array of values, really useful if you need Yup<\/a> validation for instance, and all the good stuff coming from having a union type, like static typing for property values and autocompletion from your IDE.<\/p>\r\n\r\n\r\n\r\n Wow, yet another tip on union types! What were the odds?<\/p>\r\n\r\n\r\n\r\n As we already saw, union types can be used in order to create variables or properties that can take one of a list of scalar values.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n This is useful, but kind of limiting, since you can only use the values in the list with no variation whatsoever. Everything that\u2019s not part of the list will cause a type error and TypeScript will refuse to compile.<\/p>\r\n\r\n\r\n\r\n Now, let\u2019s say you have a string that can take one value from a list that includes a bunch of very similar but not entirely static values. For instance, you may have an algorithm which makes a few attempts to perform a task that may fail, and you want to create a variable to keep the status of the algorithm.<\/p>\r\n\r\n\r\n\r\n Let\u2019s create a status<\/strong> variable, its possible values being:<\/p>\r\n\r\n\r\n\r\n Using union types the old-fashioned way, you may end up explicitly writing down the static values and just leaving a generic string<\/em> for the last ones\u2026<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\n \u2026but that\u2019s not the only way. The string values defined for a union type can actually have dynamic parts, which we can control by simply concatenating dynamic parts and static parts with template strings<\/a>.<\/p>\r\n\r\n\r\n\r\n Try it out on playground<\/strong><\/a><\/p>\r\n\r\n\r\n\r\nUtility type: Omit e Pick<\/h3>\r\n\r\n\r\n\r\n
\/\/ Starting type:\r\ninterface TypeA {\r\n id: string\r\n\r\n name: string\r\n\r\n description: string\r\n\r\n price: number\r\n}\r\n\r\n\/\/ New type created from the starting one, excluding the properties description and price:\r\ntype TypeB = Omit<TypeA, \"description\" | \"price\">;\r\n\r\n\/\/ Creating a TypeB object:\r\nconst objB: TypeB = {\r\n id: \"1001\", \/\/ OK.\r\n\r\n name: \"Name\", \/\/ OK.\r\n\r\n description: \"Description\", \/\/ Invalid: this property doesn't exist in TypeB.\r\n}\r\n\r\n<\/pre>\r\n\r\n\r\n\r\ninterface TextInputProps {\r\n label: string\r\n\r\n name: string\r\n\r\n value: string\r\n}\r\n\r\ninterface NumberInputProps extends TextInputProps {\r\n value: number\r\n}\r\n<\/pre>\r\n\r\n\r\n\r\ninterface TextInputProps {\r\n label: string\r\n\r\n name: string\r\n\r\n value: string\r\n}\r\n\r\ninterface NumberInputProps extends Omit<TextInputProps, \"value\"> {\r\n value: number\r\n}\r\n<\/pre>\r\n\r\n\r\n\r\n\/\/ Starting type:\r\ninterface TypeA {\r\n id: string\r\n\r\n name: string\r\n\r\n description: string\r\n\r\n price: number\r\n}\r\n\r\n\/\/ New type created from the starting one, with just the id and name properties:\r\ntype TypeB = Pick<TypeA, \"id\" | \"name\">;\r\n\r\n\/\/ Creating a TypeB object:\r\nconst objB: TypeB = {\r\n id: \"1001\", \/\/ OK.\r\n\r\n name: \"Name\", \/\/ OK.\r\n\r\n description: \"Description\", \/\/ Invalid: this property doesn't exist in TypeB.\r\n}\r\n<\/pre>\r\n\r\n\r\n\r\nUsing the type of a property<\/h3>\r\n\r\n\r\n\r\n
\/\/ Interface:\r\ninterface SomeInterface {\r\n id: number\r\n\r\n code: string\r\n\r\n name: string\r\n}\r\n\r\n\/\/ Declaring a variable in order to calculate the value for code:\r\nlet code: string; \/\/ <- Repeating the type\r\n\r\n\/\/ An incredibly and overwhelmingly complex initialization logic:\r\ncode = \"CODE\";\r\n\r\nconst someObject: SomeInterface = {\r\n id: 1,\r\n code: code,\r\n name: \"Name\",\r\n}<\/pre>\r\n\r\n\r\n\r\n\/\/ Interface:\r\ninterface SomeInterface {\r\n id: number\r\n\r\n code: string\r\n\r\n name: string\r\n}\r\n\r\n\/\/ Declaring a variable in order to calculate the value for code:\r\nlet code: SomeInterface[\"code\"]; \/\/ <- No repetition!\r\n\r\n\/\/ An incredibly and overwhelmingly complex initialization logic:\r\ncode = \"CODE\";\r\n\r\nconst someObject: SomeInterface = {\r\n id: 1,\r\n code: code,\r\n name: \"Name\",\r\n}<\/pre>\r\n\r\n\r\n\r\n\/\/ Interface:\r\ninterface SomeInterface {\r\n id: number\r\n\r\n code: string\r\n\r\n name: string\r\n}\r\n\r\n\/\/ Declaring an array of SomeInterface objects:\r\ntype SomeInterfaceArray = SomeInterface[];\r\n\r\n\/\/ Using the array type to get the element type:\r\nconst someObject: SomeInterfaceArray[number] = {\r\n id: 1,\r\n code: \"CODE\",\r\n name: \"Name\",\r\n}<\/pre>\r\n\r\n\r\n\r\nType narrowing: discriminated union<\/h3>\r\n\r\n\r\n\r\n
\/\/ Union type:\r\ntype SomeUnion = string | boolean;\r\n\r\n\/\/ Valid:\r\nconst someVariable1: SomeUnion = \"String\";\r\n\r\n\/\/ Valid:\r\nconst someVariable2: SomeUnion = false;\r\n\r\n\/\/ Not valid:\r\nconst someVariable3: SomeUnion = 10;<\/pre>\r\n\r\n\r\n\r\n
\/\/ Union type:\r\ntype SomeUnion = \"string_1\" | \"string_2\" | \"string_3\";\r\n\r\n\/\/ Valid:\r\nconst someVariable1: SomeUnion = \"string_1\";\r\n\r\n\/\/ Not valid:\r\nconst someVariable2: SomeUnion = \"string_5\";<\/pre>\r\n\r\n\r\n\r\n
\r\n
interface ApiResponse {\r\n status: \"SUCCESS\" | \"FAILURE\"\r\n\r\n data: any\r\n\r\n \/\/ Will only be valued on FAILURE.\r\n error_message?: string\r\n}<\/pre>\r\n\r\n\r\n\r\ninterface ApiResponse {\r\n status: \"SUCCESS\" | \"FAILURE\"\r\n\r\n data: any\r\n\r\n \/\/ Will only be valued on FAILURE.\r\n error_message?: string\r\n}\r\n\r\n\/\/ Valid: the compiler is unable to tell this is wrong.\r\nconst response: ApiResponse = {\r\n status: \"SUCCESS\",\r\n data: {},\r\n error_message: \"An error message\"\r\n}<\/pre>\r\n\r\n\r\n\r\n\r\n
interface ApiSuccessResponse {\r\n status: \"SUCCESS\"\r\n\r\n data: any\r\n}\r\n\r\ninterface ApiFailureResponse {\r\n status: \"FAIL\"\r\n\r\n data: any\r\n\r\n error_message: string\r\n}\r\n\r\ntype ApiResponse = ApiSuccessResponse | ApiFailureResponse;\r\n<\/pre>\r\n\r\n\r\n\r\ninterface ApiSuccessResponse {\r\n status: \"SUCCESS\"\r\n\r\n data: any\r\n}\r\n\r\ninterface ApiFailureResponse {\r\n status: \"FAIL\"\r\n\r\n data: any\r\n\r\n error_message: string\r\n}\r\n\r\ntype ApiResponse = ApiSuccessResponse | ApiFailureResponse;\r\n\r\n\/\/ Not valid: a SUCCESS response can't have an error_message.\r\nconst response1: ApiResponse = {\r\n status: \"SUCCESS\",\r\n data: {},\r\n error_message: \"An error message\",\r\n}\r\n\r\n\/\/ Not valid: a FAIL response must have an error_message.\r\nconst response2: ApiResponse = {\r\n status: \"FAIL\",\r\n data: {},\r\n}\r\n\r\n\/\/ Valid:\r\nconst response3: ApiResponse = {\r\n status: \"SUCCESS\",\r\n data: {},\r\n}\r\nconst response4: ApiResponse = {\r\n status: \"FAIL\",\r\n data: {},\r\n error_message: \"An error message\",\r\n}<\/pre>\r\n\r\n\r\n\r\nConst assertion (array of values as a union type)<\/h3>\r\n\r\n\r\n\r\n
const array = [\"string_1\", \"string_2\", \"string_3\"];\r\n\r\n\/\/ Inferred type:\r\n\/\/ declare const array: string[];<\/pre>\r\n\r\n\r\n\r\n
const array = [\"string_1\", \"string_2\", \"string_3\"] as const;\r\n\r\n\/\/ Inferred type:\r\n\/\/ declare const array: readonly [\"string_1\", \"string_2\", \"string_3\"];<\/pre>\r\n\r\n\r\n\r\n
const someArray = [\"string_1\", \"string_2\", \"string_3\"] as const;\r\n\r\ntype SomeUnion = typeof someArray[number];\r\n\r\n\/\/ Valid:\r\nconst someVar1: SomeUnion = \"string_1\";\r\n\r\n\/\/ Not valid:\r\nconst someVar2: SomeUnion = \"string_5\";\r\n\r\n\/\/ You can still use someArray as a regular array:\r\nif (someArray.indexOf(\"string_1\") !== -1) {\r\n console.log(\"This is valid!\");\r\n}\r\nfor (let i = 0; i < someArray.length; i++) {\r\n console.log(someArray[i]);\r\n}<\/pre>\r\n\r\n\r\n\r\nTemplate\/Dynamic union types<\/h3>\r\n\r\n\r\n\r\n
\/\/ Union type:\r\ntype SomeUnion = \"string_1\" | \"string_2\" | \"string_3\";\r\n\r\n\/\/ Valid:\r\nconst someVariable1: SomeUnion = \"string_1\";\r\n\r\n\/\/ Not valid:\r\nconst someVariable2: SomeUnion = \"string_5\";<\/pre>\r\n\r\n\r\n\r\n
\r\n
\/\/ Union type for the status:\r\ntype StatusType = \"none\" | \"success\" | \"fail\" | string;\r\n\r\n\/\/ This is valid...\r\nconst status1: StatusType = \"none\";\r\nconst status2: StatusType = \"attempt_3\";\r\n\r\n\/\/ ...but this is valid as well.\r\nconst status3: StatusType = \"Hey, I'm not a status at all!\";<\/pre>\r\n\r\n\r\n\r\n
\/\/ Union type for the status:\r\ntype StatusType = \"none\" | \"success\" | \"fail\" | `attempt_${number}`;\r\n\r\n\/\/ This is valid...\r\nconst status1: StatusType = \"none\";\r\nconst status2: StatusType = \"attempt_3\";\r\n\r\n\/\/ ...but this one isn't.\r\nconst status3: StatusType = \"Aw :(\";<\/pre>\r\n\r\n\r\n\r\n