This can really blow up :) I think typescript is smart about ultimately collapsing a type when it gets too big (something like a few thousand options) "hey, its just a string - don't go crazy now"
Metadata based programming can be very very powerful. It essentially allows you to expand an application by just adding metadata to an object, while also writing less code overall. I have found that old codebasis often have similar and/or duplicate code all over the place, which can be refactored with this metadata based driven approach. Cuts down on TONS of boilerplate.
Thanks a lot for this longer explanation! I sometimes have a harder time catching up on the really short videos but here I was able to get everything immediately.
Thanks man, 3 months ago I started learning expo, and I wanted to make routes, I suffered so much because of that, I was obligated to type routes as any...and now I know how to fix it❤
Excellent video! You often make videos about bleeding edge TS features (that I can’t use yet) or incredibly complex topics (that make me scratch my head) but this video was super accessible and easy to follow! Here’s hoping you will make more mid-level TS concepts videos.
I love as const so much. It gives so much information of the code base you're trying to work with. It's makes localization strings global constants so much more useable.
@@scylk It's very simple. You create an object that basically stores all of your strings and add an handler to dynamically change it based on the users OS language. When you mark those strings as const, TypeScript still sees the values of your default language and it's easier to know what string represents what text.
The biggest issue I've had with 'as const' is that it doesn't play well with libraries. Because of the readonly you'll get into cases where libraries are expected something like string[] and will require casting to mask the readonly. It also doesn't actually freeze the values, which can cause hard to debug bugs
Nice video! Heads up on this format on mobile because there's no TH-cam outro, the "suggested video" card appeared whilst you were still coding and blocked the code in video
Thank you sir for this great explanation. I am glad that there are so passionate typescript writers out there like yourself. Just watching this video made me understand the keyof typeof stuff and as const much easier.
As someone who doesn't know TS and just knows C#, I recoiled slightly when I saw the keyof typeof [] bit But then I remembered reflection is pretty much like that anyways in C#, accessing public (or private) members and the like.
The difference is that reflection happens at runtime. This "as const" typing happens statically at compile time, so it's typesafe -- unlike reflection. On the other hand, typescript types are not reified, whereas .net types are. So reflection over typescript types isn't possible, because the type information is erased during compilation.
So if you want as const but you don't want the whole tamale const you can define the internal object first as standard mutable object, and then put it inside in the outer const object. I.e. if you have const deep = { whatever: "/deep/whatever", }; const routes = { admin: "/admin", home: "/", deep: deep, } as const; then routes will be inferred as of type: { readonly admin: "/admin"; readonly home: "/"; readonly deep: { whatever: string; }; }
I don't get to just use typescript at work, but I sure as hell use jsdoc to the fullest in the meantime and love getting to do similar things with types. When you know for sure that you'll get auto completion and type errors, it's amazing how much less code you can end up writing. I recently set types up in such a way that I could safely turn 1000+ lines of manual references to properties on an object into just a few lines of code that auto updates, types and all.
Would you consider making a video/talk about the 'declare' keyword. While lurking into various .d.ts files I can spot all possible combinations of 'declare class', 'declare abstract class' (also: 'abstract class' alone). I have only used declare in typescript playground to mimic the existence of a function to make my types go trhough, but I can't get my head wrapped around real-life usage and how it is different from interfaces. Thanks!
Nice. Theo made a similar video of why Enums are bad. He did something similar like this object as const, but his was a string array as const. And the type Route = typeof routeArray[number]. So the difference is whether or not you want a key name associated with the routes
I first got interested in Typescript just because I thought I'd get type-checking... and weak typing was the 1990's biggest mistake. All of this auto-completion stuff in VSCode came along later as just a delightful extra little gift.
Why didnt you use enums for the routes? It looks like you only need one of the three routes at any moment. This particular example doesn't show use of as const i think. (I'm new to typescript so maybe I'm wrong, please correct me)
Right, why prefer the code in the video in place of a string enum? String enums are made for this, and they generate faster and generally smaller JS output. const enum Routes { Home = "/", Admin = "/admin", Users = "/users", }
@@programming5274 I totally agree yet I supose it is just to show that we have that option too. Imho u end with objects from other devs everytime so maybe u can just put 'as const' on them instead of refactoring to enums other people's job, idk
Awesome explanation, thank you! Do you know if TS typesystem is Turing complete? Like the programming you can do at the type level like that? I bet it is.
const obj = { username: 'abc', password: 'dce', email: 'fgh', } as const; let a: (typeof obj)[keyof typeof obj]; // Value of an object let b: Exclude; // Exclude a value from an object let c: keyof typeof obj; // Keys of an object let d: Exclude; // Exclude a key from an object
It would, but Matt has an irrational hatred for them, as seen in one of his videos "Why you shouldn't use Enums". Watch him abuse the concept of Enums and instead using magic variables. Biggest tool I've seen in TS.
As const is really cool. Didn't know we could do that. Is there not an easier way to get values of an object as a union? Like we have keys of us there not values of
What linter is "I noticed that routes has been declared, but it's never used in the code." a part of? It sounds much closer to natural language than usual error messages do.
The thing about 'as const', when not used on type parameters, is that it lies. The runtime object is, in fact, not readonly. You can get the same effect, with added runtime correctness, from Object.freeze. I consider this an extension of the 'One Source of Truth' ethos. 'as const' is, essentially, a type assertion. But I'm %100 guilty of using it everywhere so 🤷
@@mattpocockuk checked your vid about enums, so again - why dont just use enum for this case? cause enum with specified values transpiles to a simple obj as you had in your video
Because, if you read the comments here, using Enums is bad for reasons most don't understand or are not impacted by in actuality. This hacky, non-intuitive solutions to a very basic problem is somehow superior, because... Well. It isn't. Glad this video doesn't disappoint, because Matt is such a massive tool. Simply look up his "Why you shouldn't use Enums" and waste minutes of your life watching a man glorify magic variables via transitive property instead of seeing Enums as what they are.
Another trick is `as const` objects somewhat work with built-in methods while almost not losing all type info: ```typescript const ROUTES = { home: "/", admin: "/admin", users: "/users" } as const; // sadly not a tuple of literals, merely an array of literal type union const routeValues = Object.values(ROUTES).map((value) => value); export type IRoute = (typeof routeValues)[number]; export function validateRouteValue(inputValue: unknown): inputValue is IRoute { // have to coerse type there because typescript is iffy with `Array.includes()` // when it's array of string literals return routeValues.includes(inputValue as IRoute); } export function doSomethingFromValue(inputValue: IRoute): void { switch (inputValue) { case "/": case "/admin": case "/users": { break; } default: { throw new Error(`Invalid value "${inputValue satisfies never}"`) } } } ``` Achieves the same result but you also get a validation function which acts as a type predicate. The `doSomethingFromValue()` also shows how literal type unions can be paired with `satisfies` keyword to achieve exhaustive switch cases.
Hi Matt, I'm wondering if this prettify option could/should be better or not: export type ValueOf = Prettify; type Prettify = { [K in keyof T]: T[K]; } & {};
is there a shorthand for this syntax (typeof variable)[keyof typeof variable]? just curious because it's this is going to be used a lot in the code base.
Question : But when compiled, the 'as const' Object won't be frozen to JS i guess. So, if it's for heap memory optimization it is better to freeze the object a long side 'as const', isn't it ?
Hey Matt, I've come across a pattern that I think deserves a shorthand: type X = { a: string } | { b : number } // Non discriminated union const x : X = { a: "hello"} const a = !!x && 'a' in x ? x.a : undefined // works fine, but is somewhat verbose. const a = x?.a // errors out because 'a' doesn't exist on type { b: number} Is there a simpler way of picking x.a?
I'm getting kinda imposter syndrome, please explain if we really use such tricky advanced concepts in coding, or is it okay if I'm using simple intermediate level code to get my stuff done, without engaging in fancy stuff like this. Btw, amazing video 🔥🔥!!
Like everything: It really depends. If you’re not a library developer but a consumer of libraries, and you’re able to develop comfortably without leaving much bugs in the code then you’re good. If you _do_ often encounter bugs _OR_ if you want to continue growing as a programmer (which I assume is what you’d want) it’s wise to learn these concepts so you’re prepared in the less common cases where you run into them, or so you have a broader background to make better decisions.
The most underrated in TypeScript is *YOU* haha just kidding you can get tell you are respected by the way everyone else are referring to the wizard 🎉🎉🎉🎉
You can also use `as const` on individual value literals or use it on template string literals to get all possible strings.
or on array to get a tuple. For instance typeof (["a", 1] as const) is readonly ["a", 1], while typeof ["a", 1] is (string | number)[]
The template literal trick is mind blowing!
This can really blow up :) I think typescript is smart about ultimately collapsing a type when it gets too big (something like a few thousand options) "hey, its just a string - don't go crazy now"
It's ridiculous that I can't expect const as constant value. Love your vids
You can, you just need to know what is constant about your value.
Metadata based programming can be very very powerful. It essentially allows you to expand an application by just adding metadata to an object, while also writing less code overall. I have found that old codebasis often have similar and/or duplicate code all over the place, which can be refactored with this metadata based driven approach. Cuts down on TONS of boilerplate.
You can also use 'satisfies' with 'as const' to constraint the object typings, like 'as const satisfies Record', its super neat
Damn I needed this so many times and didn't know about it, thanks for sharing.
holy crap I needed this, tysm
Awesome! Thanks!
works on arrays as well:
const abc = ['a', 'b', 'c'] as const;
type ABC = typeof abc[number];
Thanks a lot for this longer explanation! I sometimes have a harder time catching up on the really short videos but here I was able to get everything immediately.
"const as const"
sounds really smart and not ridiculous at all
It makes perfect sense within the typescript syntax, and it's relationship with javascript syntax
After watching half of the video, I found an immediate use case in my TS project I'm working on. Great video!
Thanks man, 3 months ago I started learning expo, and I wanted to make routes, I suffered so much because of that, I was obligated to type routes as any...and now I know how to fix it❤
Excellent video! You often make videos about bleeding edge TS features (that I can’t use yet) or incredibly complex topics (that make me scratch my head) but this video was super accessible and easy to follow! Here’s hoping you will make more mid-level TS concepts videos.
That's worthy of a medium article mate. Very nice solution to a very popular recurring problem
YOU are the most underrated TH-camr
I use this quite often, I don't think it's underrated, I think other things may just be rated too highly... LOL
PS: Where is the Top hat and Monocle?
@@ColinRichardsonPeople do wear two monocles to make a _spectacle_ for themselves, so now he's just missing the top hat, old chap 🎩
I love as const so much. It gives so much information of the code base you're trying to work with. It's makes localization strings global constants so much more useable.
Hey can you expand a little bit on that? Sounds interesting
@@scylk It's very simple. You create an object that basically stores all of your strings and add an handler to dynamically change it based on the users OS language. When you mark those strings as const, TypeScript still sees the values of your default language and it's easier to know what string represents what text.
Just came to say this video finally helped make `as const` click for me. Thanks for the info, Matt!
"Object.values on a type level" trick is pretty neat. Thanks!
You guys are lucky I'm dumb, I asked the question that inspired this video :)
Thanks for all you do Matt, I learned a whole lot.
Was using an enum for a radio group in Zod and discovered this. Never went through the trouble of understanding it, though. Thanks 👍🏿
I did not know as const prevented the object being changed - thanks!
That's absolutely brilliant! I wasn't super sure what "as const" was doing, thanks for clarifying that!
Sometimes I utilize this tool to manage database names, collections, roles, etc., enabling me to infer values instead of strings :).
Godly gift of explanation.
The biggest issue I've had with 'as const' is that it doesn't play well with libraries. Because of the readonly you'll get into cases where libraries are expected something like string[] and will require casting to mask the readonly.
It also doesn't actually freeze the values, which can cause hard to debug bugs
The best and simplest explanation of "as const"!
Watched small video - huge power acquired. Thank you!
Nice video! Heads up on this format on mobile because there's no TH-cam outro, the "suggested video" card appeared whilst you were still coding and blocked the code in video
Amazing video.
Such really good pedagogy, loved it, even if I was already very familiar with as const and the other notions sumed up.
That was a whole lot of fantastic stuff that will immediately be used
Thank you sir for this great explanation. I am glad that there are so passionate typescript writers out there like yourself. Just watching this video made me understand the keyof typeof stuff and as const much easier.
This is such a helpful feature. I'll be using this all the time now, thank you
This is so beautiful that i want to cry.
Almost as good as 'as any'!
I love your typescript content, thanks
i was in a live stream a few days ago on this,learned so much
Finally... now I understand it. Thank you Matt.
You just saved me wtf. I was looking for a solution like this yesterday
What do you prefer “as const” or enum in cases like in video?
Needed this a few months ago 😂 excellent content on this channel dude keep it up
Simply a typescript magician
This channel is also underrated. awesome video! you just got a new subscriber here
Finally something from youtube I will actually use
As someone who doesn't know TS and just knows C#, I recoiled slightly when I saw the keyof typeof [] bit
But then I remembered reflection is pretty much like that anyways in C#, accessing public (or private) members and the like.
The difference is that reflection happens at runtime. This "as const" typing happens statically at compile time, so it's typesafe -- unlike reflection.
On the other hand, typescript types are not reified, whereas .net types are. So reflection over typescript types isn't possible, because the type information is erased during compilation.
Very nice ticks! keep them comming sensei!
Wow great video especially as a new typescript developer, I subscribed
Oh cool! I knew it for array to union, but not for object to union. Thanks!
Amazing! I needed this earlier today!
Niiiiice ! I always forget how to target the type of keys and values of objects 😅
So if you want as const but you don't want the whole tamale const you can define the internal object first as standard mutable object, and then put it inside in the outer const object.
I.e. if you have
const deep = {
whatever: "/deep/whatever",
};
const routes = {
admin: "/admin",
home: "/",
deep: deep,
} as const;
then routes will be inferred as of type:
{
readonly admin: "/admin";
readonly home: "/";
readonly deep: {
whatever: string;
};
}
Really great.
You are a great teacher 😊
Thx from France.
I don't get to just use typescript at work, but I sure as hell use jsdoc to the fullest in the meantime and love getting to do similar things with types. When you know for sure that you'll get auto completion and type errors, it's amazing how much less code you can end up writing. I recently set types up in such a way that I could safely turn 1000+ lines of manual references to properties on an object into just a few lines of code that auto updates, types and all.
Would you consider making a video/talk about the 'declare' keyword. While lurking into various .d.ts files I can spot all possible combinations of 'declare class', 'declare abstract class' (also: 'abstract class' alone). I have only used declare in typescript playground to mimic the existence of a function to make my types go trhough, but I can't get my head wrapped around real-life usage and how it is different from interfaces. Thanks!
Nice. Theo made a similar video of why Enums are bad. He did something similar like this object as const, but his was a string array as const. And the type Route = typeof routeArray[number]. So the difference is whether or not you want a key name associated with the routes
Thank you very much Mr Matt!
type Values = T[keyof T];
const routes = {
home: '/',
admin: '/admin',
users: '/users'
} as const;
type Route = Values; // Route = "/" | "/admin" | "/users"
I first got interested in Typescript just because I thought I'd get type-checking... and weak typing was the 1990's biggest mistake. All of this auto-completion stuff in VSCode came along later as just a delightful extra little gift.
Why didnt you use enums for the routes? It looks like you only need one of the three routes at any moment. This particular example doesn't show use of as const i think. (I'm new to typescript so maybe I'm wrong, please correct me)
Right, why prefer the code in the video in place of a string enum? String enums are made for this, and they generate faster and generally smaller JS output.
const enum Routes {
Home = "/",
Admin = "/admin",
Users = "/users",
}
/* String enum */
const enum Routes {
Home = "/",
Admin = "/admin",
Users = "/users",
}
const goToRoute = (route: Routes) => {
console.log(route);
}
goToRoute(Routes.Home);
console.log("----------------------");
/* as const */
const rts = {
home: "/",
admin: "/admin",
user: "/users",
} as const;
type Rte = (typeof rts)[keyof typeof rts];
const goToRt = (route: Rte) => {
console.log(route);
}
goToRt(rts.home);
@@programming5274 Yes!
Because Matt has a hate boner for them and prefers magic variables. Sharing a codebase with him can be only the first step of hell.
@@programming5274 I totally agree yet I supose it is just to show that we have that option too. Imho u end with objects from other devs everytime so maybe u can just put 'as const' on them instead of refactoring to enums other people's job, idk
Can we use enum for store routes and avoid create additional types?
Awesome explanation, thank you!
Do you know if TS typesystem is Turing complete? Like the programming you can do at the type level like that? I bet it is.
It is!
const obj = {
username: 'abc',
password: 'dce',
email: 'fgh',
} as const;
let a: (typeof obj)[keyof typeof obj]; // Value of an object
let b: Exclude; // Exclude a value from an object
let c: keyof typeof obj; // Keys of an object
let d: Exclude; // Exclude a key from an object
I may have agreed, but even better is the new const in generics feature.
Nice quick dive into using "as const" with objects! I know it's a useful TypeScript feature when I find myself using it intuitively as I'm coding.
Now using rust and coming from c this is really funny to me how JS devs (i am a 4 years js/ts dev) go nuts with typing systems
Amazing so concise and clean.
Would an enum work the same?
It would, but Matt has an irrational hatred for them, as seen in one of his videos "Why you shouldn't use Enums". Watch him abuse the concept of Enums and instead using magic variables. Biggest tool I've seen in TS.
Awesome sharing!
I now understand Rich Harris. We are packing up and moving to Jsdoc
Great video, typescript is beautiful
As const is really cool. Didn't know we could do that. Is there not an easier way to get values of an object as a union? Like we have keys of us there not values of
Videos are very useful and clear, thanks
What linter is "I noticed that routes has been declared, but it's never used in the code." a part of? It sounds much closer to natural language than usual error messages do.
It's the TypeScript error translator I built:
marketplace.visualstudio.com/items?itemName=mattpocock.ts-error-translator
@@mattpocockuk Oh neat
The thing about 'as const', when not used on type parameters, is that it lies. The runtime object is, in fact, not readonly. You can get the same effect, with added runtime correctness, from Object.freeze. I consider this an extension of the 'One Source of Truth' ethos. 'as const' is, essentially, a type assertion.
But I'm %100 guilty of using it everywhere so 🤷
You didn't talk about: "as const satisfies Record "
I started using a lot of "as const satisfies typeX", I'm creating a lib and it's helping me a lot
Great video and example.
Why not using enum for this case ?
Check my video on enums
@@mattpocockuk checked your vid about enums, so again - why dont just use enum for this case? cause enum with specified values transpiles to a simple obj as you had in your video
Brilliant. Instant follow
"as const or how to implement a real enum in typescript" 😂
4:05 me knowing new ts magic
thank you, you are a life saver!
In this case, why not use enums?
Because, if you read the comments here, using Enums is bad for reasons most don't understand or are not impacted by in actuality. This hacky, non-intuitive solutions to a very basic problem is somehow superior, because... Well. It isn't. Glad this video doesn't disappoint, because Matt is such a massive tool. Simply look up his "Why you shouldn't use Enums" and waste minutes of your life watching a man glorify magic variables via transitive property instead of seeing Enums as what they are.
Awesome tip here. Thank you @mattpocockuk for sharing this.
But what benefit it adds in comparison to string enums?🥺
Wondering the same lol
this is beautiful
Just wow. Thank you.
Another trick is `as const` objects somewhat work with built-in methods while almost not losing all type info:
```typescript
const ROUTES = {
home: "/",
admin: "/admin",
users: "/users"
} as const;
// sadly not a tuple of literals, merely an array of literal type union
const routeValues = Object.values(ROUTES).map((value) => value);
export type IRoute = (typeof routeValues)[number];
export function validateRouteValue(inputValue: unknown): inputValue is IRoute {
// have to coerse type there because typescript is iffy with `Array.includes()`
// when it's array of string literals
return routeValues.includes(inputValue as IRoute);
}
export function doSomethingFromValue(inputValue: IRoute): void {
switch (inputValue) {
case "/":
case "/admin":
case "/users": {
break;
}
default: {
throw new Error(`Invalid value "${inputValue satisfies never}"`)
}
}
}
```
Achieves the same result but you also get a validation function which acts as a type predicate.
The `doSomethingFromValue()` also shows how literal type unions can be paired with `satisfies` keyword to achieve exhaustive switch cases.
You can use ts-reset to fix that Array.includes issue.
Made me subscribe. Thank you very much. 👍
I love your videos. Very insightful, fun, and straight to the point
Hi Matt, I'm wondering if this prettify option could/should be better or not:
export type ValueOf = Prettify;
type Prettify = {
[K in keyof T]: T[K];
} & {};
How about routes with matching variables like '/users/:id' that match /users/3 ?
That's brilliant!
is there a shorthand for this syntax (typeof variable)[keyof typeof variable]? just curious because it's this is going to be used a lot in the code base.
Question : But when compiled, the 'as const' Object won't be frozen to JS i guess. So, if it's for heap memory optimization it is better to freeze the object a long side 'as const', isn't it ?
Normally I would an enum in this case like "enum routes" and avoid declaring the type. What do you think?
“const x as const” just feels weird to write 😂
And this is because, I am assuming from the pop-up, enums should not be used?
Hey Matt, I've come across a pattern that I think deserves a shorthand:
type X = { a: string } | { b : number } // Non discriminated union
const x : X = { a: "hello"}
const a = !!x && 'a' in x ? x.a : undefined // works fine, but is somewhat verbose.
const a = x?.a // errors out because 'a' doesn't exist on type { b: number}
Is there a simpler way of picking x.a?
Search for "ExclusifyUnion", there's a good stack overflow answer with an explanation
I'm getting kinda imposter syndrome, please explain if we really use such tricky advanced concepts in coding, or is it okay if I'm using simple intermediate level code to get my stuff done, without engaging in fancy stuff like this. Btw, amazing video 🔥🔥!!
Like everything: It really depends. If you’re not a library developer but a consumer of libraries, and you’re able to develop comfortably without leaving much bugs in the code then you’re good.
If you _do_ often encounter bugs _OR_ if you want to continue growing as a programmer (which I assume is what you’d want) it’s wise to learn these concepts so you’re prepared in the less common cases where you run into them, or so you have a broader background to make better decisions.
The most underrated in TypeScript is *YOU* haha just kidding you can get tell you are respected by the way everyone else are referring to the wizard 🎉🎉🎉🎉
'as const' is also nice cause it saves you from having to do Object.freeze over and over.
this video is amazing!
I guess your example is similiar to the usage of enum (?). are there any other example besides that?
4:05 ❤