Xtykutl

interface Activity {

    eat: () => void

}



interface Person {

    activity?: Activity

}



const activity = <T extends Person>(person: T) => ({

    eat: person.activity && person.activity.eat

})



const tom = {

    activity: {

        eat: () => {}

    }

}



const tomAct = activity(tom)

tomAct.eat() // should know `eat` does exist



const bobAct = activity({})

bobAct.eat // should know `eat` is undefined

You can see tomAct.eat will return eat: (() => void) | undefined but tomAct in this case knowns that eat: (() => void and bobAct is known undefined.

Does Typescript support this case? How can I solve that?

===

"typescript": "^3.1.2",

Your problem is that control flow analysis doesn't really work very well on generics. The compiler is essentially widening T to Person for the purposes of control flow analysis (figuring out what type person.activity && person.activity.eat will be), so the inferred return type of activity() is the same as that of the concrete (non-generic) version of the function:

const activityConcrete = (person: Person) => ({

  eat: person.activity && person.activity.eat

}); // {eat: ()=>void | undefined}

In order to get the behavior you want you either need to walk the compiler through the analysis (which is sometimes impossible) or just assert the return type you expect. Traditionally what you'd do here is to use overloads to represent the relationship between input and output types:

function activity(person: { activity: Activity }): Activity;

function activity(person: { activity?: undefined }): { eat: undefined };

function activity(person: Person): { eat: Activity['eat'] | undefined };

function activity(person: Person): { eat: Activity['eat'] | undefined } {

  return {

    eat: person.activity && person.activity.eat

  }

}

As of TypeScript 2.8 you can use conditional types to represent the same thing:

type PersonEat<T extends Person> = T['activity'] extends infer A ? 

  A extends Activity ? A['eat'] : undefined : never;



const activity = <T extends Person>(person: T) => ({

  eat: person.activity && person.activity.eat

} as { eat: PersonEat<T> })

Either way should result in similar behavior:

const tom = {

  activity: {

    eat: () => {}

  }

}

const bob = {};



const tomAct = activity(tom)

tomAct.eat() // okay 🙂



const bobAct = activity(bob)

bobAct.eat // undefined 🙂

So that works.

Please note that there's a bit of a wrinkle with how it treats a Person without an activity. The type of bob above is {}, which is treated as a top type for objects, meaning that it absorbs any other object type you union with it. That is, in:

const tomOrBob = Math.random() < 0.5 ? tom : bob; // type is {}

it is inferred that tomOrBob is of type {} | {activity: Activity}, which is collapsed to just {}. So the compiler forgets that tomOrBob might have an activity. And that leads to the following incorrect behavior:

const tomOrBobActivity = activity(tomOrBob);

tomOrBobActivity.eat; // undefined 🙁 but it should be (()=>void) | undefined

If you're okay with that overzealous undefinedness, fine. Otherwise, you need to explicitly tell the compiler to remember that activity is missing from bob:

const bob: { activity?: undefined } = {}; // bob definitely is missing activity



const bobAct = activity(bob);

bobAct.eat // still undefined as desired 🙂



const tomOrBob = Math.random() < 0.5 ? tom : bob;



const tomOrBobAct = activity(tomOrBob);

tomOrBobAct.eat; // (() => void) | undefined 🙂

And that behaves as desired.

Okay, hope that helps. Good luck!

Typescript is a transpiler that works on compile time, therefore it can know only the things that are known at that time.

You requirement is runtime requirement, the value of some property will be known only at runtime, therefore it is not possible to do with TS.