No, there is a long and old discussion on github on why they won't do it. Just write your own function. Easy solution.

@@DemanaJaire could you link us the github discussion please?

@@grgry06 A very good example of why it's not a good idea is this: const x = { a: 1, b: 2, c: 3 } const y: { a: 1; b: 2 } = x for (let k in Object.keys(y)) { // what should be the type of k? // keyof typeof y would return 'a' | 'b' // but in reality the array would consist of // ['a', 'b', 'c'] } That's why you are provided with a solution that you can use at your own risk.

@@DemanaJaire Sorry, but your example doesn't make sense as it's not possible to assign x to y. The second statement here is not possible: (I did try it out in typescript to be sure and indeed it is not possible) const x = { a: 1, b: 2, c: 3 } const y: { a: 1; b: 2 } = x

@@asdfasdfuhf try this instead const x = { a: 1, b: 2, c: 3 } const y: { a: number; b: number } = x

I had this same issue

Same issue here, thank you for this solution!

Thanks

Sure - some TS patterns are only possible if you add a wrapper function. But these scenarios are pretty few and far between and I've never found that it provides a _worse_ experience for users. Adopting TS in my teams has pretty much always been a boon for our users.

@@mattpocockuk Oh yeah, I totally agree, I've barely encountered any situations where I had to rewrite/refactor, and in the cases that I did it actually resulted in a better structured code, overall TypeScript is amazing. You start bearing it's fruits when you have a big project and you're no longer afraid something might break if you change stuff. I guess all I'm trying to say is that it's a matter of personal preference and it feels a bit wrong to me having to write runtime code for the purpose of type checking, after all that's what TS is there for, better to keep those two separate. But as you said, it's highly unlikely that it will degrade experience or degrade performance by a noticeable margin. So TL;DR, I've seen people do it, just not a big fan of. But I suppose it's not the end of the world if you *have* to use it either.

​​@@dechobarca you can always do: const person = { age: 18, name: 'Me' } Object.keys(person).forEach((key: keyof typeof person) => { console.log(person[key]) }) It doesn't look as elegant but it gives you the same type safety

​@@nathantorquato9777 That's clever, thanks for the idea. I've actually found similar and more advanced strategies for Object.values and Object.entries since watching this, but the video was a great starting point :)

@@dechobarca that’s cool. Do you mind sharing some examples? I’d be very interested to see some new cool tricks

Makes sense!

@@mattpocockuk This is what I was able to come up with since: ``` type NonSymbolPropertyKey = Exclude; type StringConvertedPropertyKey< Obj, Key = keyof Obj > = NonSymbolPropertyKey; Object.keys(o) as StringConvertedPropertyKey[]; ``` Feel free to steal it as content for a video if you think it is good enough :)

@@joostkersjes4349 "xdescribe" or "xit" would be another solution :D

It's a bug on KZfaq's side - it'll look like that until it's released!

Just watched this one that I think does what you want kzfaq.info/get/bejne/eJ2pmrV6tsm1gHk.html

Not in all cases! Sometimes assertions are the best way to tell TS what to do when it can't figure it out itself.

You could do that - I've got an upcoming tip about this pattern and it certainly works well here.

@@mattpocockuk Great series BTW. Helps me a lot, so thank you.

Yes, but then you need to do this every time you use Object.keys, which isn't fun. You should try to work _with_ TS's inference, not against it.

Note the helpful errors: objectkeys.ts(1, 28): This type parameter might need an `extends {}` constraint. objectkeys.ts(1, 28): This type parameter might need an `extends object` constraint.

You can write (notice the comma). This makes the parser notice it is not a tag.

This video might be on an old version of TS.

I just got the same thing.... Think it's something new because I have used this exact piece of code before without trouble....

It happens in TS 4.8 + I found ugly workaround like this ```ts export const objectKeys = (obj: Obj): (keyof Obj)[] => { if (obj) { return Object.keys(obj) as (keyof Obj)[]; } return []; }; ```

@@JurrAFC thank you, I'll try that one out.

Late reply, but you will need to add an ‘extends object’ constraint to the generic

@@0tickpulse173 nice, it works. thanks!

Could you elaborate? They're different methods.

@@mattpocockuk Sorry, I guess that’s my homework. This is my day to day use case with react I previously used Object.keys(myObj).map(key => myObj[key] ) Then I started using Object.entries(myObj).map(([key, value]) => value )

That'll result in a type error

@@mattpocockuk I had just checked it in Ts Playground. Perfect typing and no errors

​@@eugenbondarenko8286 Perhaps your settings and mine differ, but it errors in strict mode: tsplay.dev/mAKy8w

@@mattpocockuk yea, i see now. Probably had wrong version or bugged TS site. Thank you for effort tho

Sure, but I don't think it's safe to do that. Object.keys is loose for a reason.

@Matt Pocock

stackoverflow.com/questions/55012174/why-doesnt-object-keys-return-a-keyof-type-in-typescript

@@mattpocockuk Then how does `for ( const k of objectKeys(point) ) { fn(k); } fix that? it seems it's the exact same problem?

@@ColinRichardson Unsure what you're referring to?

@@mattpocockuk You linked to a stack overflow which states the reason for it not being done in the lib. Your video shows wrapping of Object.keys, but has the exact same problem of the reason why it should not be done in the lib.. So, if it should not be done in the lib, it should not be done in the function that you showed us in your video. So, I am asking if they have the exact same problem, how is this video a solution? or if this video IS a solution, then why is putting this solution into the lib.es5.d.ts also a solution?

@@ColinRichardson Right - this video is a solution for the cases where you know the keys up front. Object.keys should _not_ in general be done like this. But it is useful to know how to extract the keys from an object dynamically - and makes for a good example.