Question: Why do RecipientsID and RecipientsObject exist?

[bingenito]

Question Area

[x] Context Data

Question

Why do RecipientsID and RecipientsObject exist at the code level when the documentation for fdc3.email has a recipients property of fdc3.contact or fdc3.contactList. That doesn't match the code. Contact has an id property of type ContactID, ContactList has a contacts property of Contact[] but RecipientsObject has an optional id property of type RecipientsID which has a property contacts. This is three different type of types to look for when implementing this.

[kriswest]

@bingenito This appears to be the fault of the Typescript generator which is taking this oneOf:

FDC3/src/context/schemas/email.schema.json

Lines 9 to 13 in dc42f96

	"recipients": {
	"oneOf": [
	{ "$ref": "contact.schema.json#" },
	{ "$ref": "contactList.schema.json#" }
	]

and creating RecipientsObject from the union of the two types (although treating it more like an intersection) + RecipientsID as a copy of ContactID to use on the new type.

The result is a set of types that probably do validate most contexts correctly, but would also allow a weird hybrid that's not valid. They should really be expressing a union instead - and based on our previous chats about the difficulty of union types in other languages might have been better defined without the union (always use ContactList). That in turn always prompts me to think about whether we should be negating the need for the list types as well will some form of generics support...

The Type generation from JSON Schema is performed by quicktype. I think someone is going to need to take a look at any options available within quicktype to see if we can get better output from it - or we consider moving to manually maintained types to give us more control.

[kriswest]

@bingenito BTW have you considered attempting to generate your C# types from the json schema via quicktype? I'm wondering if it will take a different approach for C# code generation.

[kriswest]

Using the quicktype app I'm getting the same behavior:

C# output creates a recipients class still that is a bizarre merge of the two available types (Contact and ContactList):

[bingenito]

@bingenito BTW have you considered attempting to generate your C# types from the json schema via quicktype? I'm wondering if it will take a different approach for C# code generation.

I wanted to have handlers and callbacks be based on a common base type Context with type property while still allowing fully typed ID properties, so went with went with a more manual route involving a base Context<T>, so something like Instrument is Intrument: Context<InstrumentID>. I'll reconsider a generator if it makes things easier because writing these by hand is not fun (although it allowed me to see the issues I've entered in).

[mistryvinay]

hi @bingenito did you need any more support with the above? I have added this issue to this weeks discussion group meeting (#903) if you would like to discuss further.

[kriswest]

closed due to inactivity