Support RequiredKeys and OptionalKeys

[malash]

Demo:

type Obj = {
  a: number;
  d: number | undefined
  b?: string;
  c?: boolean;
  e?: number | undefined
};
type A = RequiredKeys<Obj>; // "a" | "d"
type B = OptionalKeys<Obj>; // "b" | "c" | "e"

https://stackoverflow.com/questions/53809467/typescript-how-get-optional-keys-of-type

EDIT1: Added edge cases

[piotrwitek]

Looks useful, accepting PR's!

Requirements:
Add 2 new types to the public API based on the OP demo usage.

• RequiredKeys
• OptionalKeys

If you want to introduce some helper types please keep them private

[levenleven]

I'd like to add NullableKeys as well.
With strictNullChecks enabled can be implemented as

type PickKeys<T extends object, TValue extends null | undefined> = NonNullable<
  { [K in keyof T]: TValue extends T[K] ? K : never }[keyof T]
>

type NullableKeys<T extends object> = PickKeys<T, null>
type OptionalKeys<T extends object> = PickKeys<T, undefined>
type RequiredKeys<T extends object> = Exclude<keyof T, OptionalKeys<T>>

Playground (works only with strictNullChecks)

[piotrwitek]

@levenleven
Although they might seem useful API surface will expand making it complex and hard to learn.
Now I think that maybe it would be better to add more generic types to allow consumer for better composability making it easier to master and allowing for even better flexibility and extendability:

type ExtractKeys<T extends object, TKeyValue extends any> = NonNullable<
  { [K in keyof T]: TKeyValue extends T[K] ? K : never }[keyof T]
>;
type ExcludeKeys<T extends object, TKeyValue extends any> = Exclude<keyof T, ExtractKeys<T, TKeyValue>>;

type Foo = {
  str: string;
  num: number;
  date: Date | null;
  bool?: boolean;
};

type NullableProps = Pick<Foo, ExtractKeys<Foo, null>>;
type OptionalProps = Pick<Foo, ExtractKeys<Foo, undefined>>;
type RequiredProps = Pick<Foo, ExcludeKeys<Foo, undefined>>;

What do you think?

EDIT: We might add both if that make sense

[levenleven]

I think ExtractKeys/ExcludeKeys are good for flexibility, but I'd also include shortcuts to RequiredKeys and others.

Now regarding names:

1. Key helpers - maybe it would be clearer if we'd call them ExtractKeysOfType or KeysAssignableTo?
2. Property set helpers (not sure if needed or in scope of this proposal) - PickNullable, PickOptional etc. (to align with Pick naming convention)

[piotrwitek]

I agree we could greatly benefit from both general helpers and shortcuts.

New API Proposal for extending Pick/Omit and Object-Keys Helpers

...

Moved to #59

[levenleven]

I'm for OptionalKeys. Also I don't think there's inconsistency with Partial, because props can optional but can't be partial, and the other way around - object can be partial but not optional

[piotrwitek]

I understand your semantics argument, but in reality Partial equals Optional. In general, I think Optional would be a better name and for that reason, the best would be to use OptionalKeys and create an alias (Optional) for Partial as well to keep the API consistent.

[malash]

I find a bug in the StackOverflow version.

type KeysOfType<T, U> = { [K in keyof T]: T[K] extends U ? K : never }[keyof T];
type RequiredKeys<T> = Exclude<KeysOfType<T, Exclude<T[keyof T], undefined>>, undefined>;
type OptionalKeys<T> = Exclude<keyof T, RequiredKeys<T>>;

type Obj = {
  a: any;
  b?: string;
  c?: boolean;
};
type A = RequiredKeys<Obj>; // "a" | "b" | "c"
type B = OptionalKeys<Obj>; // never

[malash]

And another issue is that how to handle { d: number | undefined } ?

Should its RequiredKeys be 'd' or never ?

[malash]

@piotrwitek I think it could be better if we create a new issue for the new API proposal ?

[levenleven]

@malash see above working version.

Regarding number | undefined - I think this should be treated as optional, because what ? essentially does - is adding undefined to the type (with strictNullChecks of course)

[malash]

type A = Required<{ a: number | undefined }>;
type B = Required<{ a?: number }>;

A is still { a: number | undefined }

B is { a: number }

[levenleven]

@malash interesting, seems you're right. We'll need to tweak Required/Optional resolution

[eps1lon]

Depending on the implementation (Object.prototype.hasOwnProperty can make a difference here) those are not the same thing at run-time. The first one still requires explicitly setting a to undefined while you can do this implicitly with the second one by omitting a. You could argue that Required is working as intended.

[levenleven]

Yeah, now it makes much more sense to tackle RequiredKey/OptionalKeys separately from all the other helpers proposed here. All the others are still perfectly valid

[eps1lon]

Right because I would argue that RequiredKeys should include number | undefined. After all the key is required. Just not the value.