Question: Handling IntentResult

[Roaders]

Question Area

• [ ] App Directory
• [x] API
• [ ] Context Data
• [ ] Intents
• [ ] Use Cases
• [ ] Other

Question

I am currently trying to implement handling the result of the IntentHandler when we are calling raiseIntent. The return type of IntentHandler is:

export type IntentResult = Context | Channel | void;

and the IntentResult (with a duplicate name) that we need to send within the RaiseIntentResultResponse is:

export interface IntentResult {
    context?: Context;
    channel?: Channel;
}

What is the best of determining if the result returned from the IntentHandler is a Channel or a Context? Context defines a type: string property (everything else is optional) which is also present on Channel. Channel defines id: string (the only other required field) but it is quite possible that id is also present on Context as we have [property: string]: any;.

As far as I can see there is no way of reliably telling what has been returned. The closet we could come is checking for id but that is not infallible.

[Roaders]

ok... I was wrong. id is defined on Context but it is an object. This is what we can use.

[kriswest]

@Roaders The type and the interface represent the same thing in two different encodings (TypeScript for the API, TypeScript generated from JSON schema in the Desktop Agent Communicaiton protocol). They are functionally equivalent (and empty IntentResult object represent a void return - you should still send that message at indicates that the handler finished and there was a void result).

id may not be present in all context types. Its very common, but technically optional.

Both Context and Channel have type fields - but the values for Channel are constrained to: "user" | "app" | "private" so I would use that as the most reliable means of differentiation. We should probably ban those as COntext types to be sure!

[Roaders]

yes I saw the values for type but currently there is nothing that stops you creating a a context object with a type of user - unless I am missing something. I am not sure how easy it would be to ban them using typescript either.

[kriswest]

Technically the context spec requires contexts to be namespaces (fdc3. for standard types) - but this is hard to enforce via typescript. We could state reserved values.

In TypeScript we differentiate by looking for functions like addContextListener, but you don't have that in JSON. So... id is either a string or object, or you look for the displayMetadata property. No compelling answers I'm afraid.

[Roaders]

well in typescript you could actually have: ts

type: `${string}.${string}`;

which would require that the type does have a period in it. This may well break apps though that are using context with no period.

I am not sure how that would work with the json schemas though

[kriswest]

JSON schema can apply regex to control strings - but it doesn't generate out into TypeScript through QUicktype at the moment...