Видео

You could use the following : [K in Extract<keyof T, string> as ......] to avoid the intersections with string

The question is why? This is the type gymnastics that puts people off. If it's developer help you're after, put an example in a JSDoc, if it's some sort of forcing an error, use a validator. How much time did you spend hovering around and not solving the actual problem at hand!?

I think to avoid this hard to read black magic - TS syntax should allow writing functions to define types - I.e. you could write simple recursive function that traverses tree of the keys, which would look much more readable.

I think TS, at a conceptual level, must've been built on top of works in set theory published by pure mathematicians This thing seems to come straight out of a college level math textbook lmao

i assume/hope things must have changed as of September 2024 🥲🥲

Really helpful, would love to hear you talk more about various TS/JS topics! Cheers 🙌

This is a great explainer, though didn't explain what I was looking for Still, big thumbs up!

my brain explode when it comes to how to dynamic extract key or value from a nested object, espcially when you use [K in keyof T as (...)], really weired syntax, hard to understand why this works , and I found this less code also works, but not quite sure why it works type PathTo<T extends Record<string, unknown>> = keyof { [K in keyof T as T[K] extends Record<string, unknown> ? `${K & string}.${PathTo<T[K]>}` : K]: unknown; };

Very good video man

Sick vid man!

Oh hey, the thing I've spent the last 3 weekends trying to do...

I love that you incrementally build up the solution by solving each little problem.

Awesome! Do you think you have time to continue part 2 to explain the module more in depth?

I don't really like taking the keyof a mapped type. I think it's nicer to take a helper instead: type PathInto<T extends Record<string, any>, K = keyof T> = K extends string ? T[K] extends string ? K : `${K}.${PathInto<T[K]>}` : never; Or without the helper: type PathInto<T extends Record<string, any>> = keyof T extends infer K ? K extends string ? T[K] extends string ? K : `${K}.${PathInto<T[K]>}` : never : never;

The worst tutorial i've ever seen

I did something similar for another project, I made K extends string the outermost ternary operation so that in the true branch I didn’t need to do K & string, as in that branch K is narrowed to some string type. I used this type (I called it dot path) to map keys of one type to keys of another type based on a suffix in each key. Type level programming is my favorite feature of TypeScript (also probably the only feature I like tbh) because it feels like doing a proof, and also because the literal types make for a really good developer experience since the LSP can suggest strings from that type.

That's amazing! What resources can I use to level up my type-level programming skills?

All of that just to have some intellisence on (string): string 😁

This video is Amazing ! I needed a lite translation hook for my project and didn't want to fiddle with libraries for it. This is just perfect! I adapted it to be able to loop trough several files of translate keys and it works wonderfully ! Thank you for that!

use vscode terminal T_T

Great explanations, but personally would frown if I saw this in a project. Mental gymnastics and cognitive overload ;)

Brilliant. Thank you!!

This is starting to look like Haskell code, haha.

I actually used this in our company to name the fields in the api responses as we get Keys that are in objects or arrays, and we use them parsed in a specific way (with __ instead of .) and It was so difficult for me to manage to do this. I think this is greatly explained and would've been so Happy to find this video when I did this 😂

great explanation! I didn't know about that `K & string` trick, very useful :) thanks

7:37 It only works on Unix systems (Linux, Mac OS) and it doesn't work on Windows. The universal solution is to use the rimraf library.

That's some next level dogshit, ngl.

Please more content like this, I am engaged in building libraries for my websites and client sites, always running into brick walls over design patterns as it is hard to track down quality lessons for this kind of stuff

Very interesting, thanks

Excellent video! This is simple and clear, exactly what i was looking for. I just subbed to your channel and i am waiting for more videos like this one!!

Why didn't OP just define types to lie about how EventEmitter works, to get the same benefits?

Yeah, ok this is really bad. You need to pick up event patterns from different languages rather than what you are doing. this is simply just bad code created from a very corky js community. Define your events as classes and stop separating the event type from the payload. This is just bad.

au, my brain!

Great rundown thanks Simon.

Great 👏 thanks!

Wow, that's crazy :D didn't know that was possible!

Cool, my version without `& string` const data = { env: { name: "", payload: { price: 0, size: 0, }, }, }; type DataType = typeof data; type PathsInRecord<OBJ extends Record<string, any>> = keyof { [KEY in keyof OBJ as OBJ[KEY] extends object ? KEY extends string | number ? PathsInRecord<OBJ[KEY]> extends string ? KEY | `${KEY}.${PathsInRecord<OBJ[KEY]>}` : never : never : KEY]: never; }; type res = PathsInRecord<DataType>; const a: res = "env"; const a0: res = "env.name"; const a1: res = "env.payload"; const a2: res = "env.payload.price";

I tried this with SendGrid instead of Mailgun, and the main problem with it was that my messages would always end up classified as Promotions on Gmail users’ accounts. It was enough to convince me that, to guarantee mail delivery and correct classification, it’s probably not a good idea to use SMTP servers aimed at promotional or automated use for my personal messages.

So glad to have discovered this channel. I'm fairly new to Typescript and I'm just overwhelmed with all the options and module types and and and... Thanks for helping with this concise explanation. More on modules would be great.

Finally. Thank you!

I was casually watching this in the living room and was really excited because it's just extraordinarily good content. But as soon as I was done I turned around to see my girl friend judging me. She called me a nerd and now I am happy in two ways. :> Thank you for sharing this and "yolo"

I have though about this many times and though it was impossible in TS. Now you've clear my mind. Thank you!

Great video! My version for this case would be type PathTo<T extends Record<string, unknown>> = keyof { [K in keyof T as T[K] extends Record<string, unknown> ? `${K & string}.${PathTo<T[K]> & string}` : K & string]: any; };

This is amazing black magic and I’m glad I watched the video. If I ever saw anyone submit anything remotely similar to this in a PR it would get a Deny so fast my left click would break the sound barrier.

very educational video 👍 would be great to see more videos about complex types in TS and you find a solution for them

neat!, now im gonna yoink this

Man, I've just discovered your channel, this is the 3rd video I've watched and all your videos are little gold nuggets :D I love your content.

Once again, great video. One question though, you've mentioned that the two most important options are "strict": true; and "noUncheckedIndexedAccess": true,. How about option "strictNullChecks"? This one should be pretty important too no?

Wow great stuff. You've just gained a new subscriber :). I've been getting more and more into Typescript and I often struggle with recursion. I think the "variables" name in types aren't always the best :) things like K and T aren't very descriptive and it makes it really hard to understand what is going on :). I think one nice thing would be to comment the most challenging parts so you know what is going on. But I loved your process though, thank you very much the great video.

Man, that's rough! LOL It's an elegant solution but it's not very legible. It seems like once we get to the level of complexity where we need to invoke the term "type-level programming" that Typescript's terse syntax doesn't always let you express things in a way that's suitable for maintainability. You see the same kind of shortcomings with complex regular expressions. It starts to feel like you would almost want an extended syntax to deal with that sort of thing. Some languages actually do have alternative ways to build regexes that are more verbose but easier to read. Maybe MS will do something similar for Typescript in the future.