In iOS I'm pretty sure all / most of the fields are string | null (NSString | null) properties however only company seems to have this definition, the majority being required strings. The outcome is that you need to provide a lot of empty string properties when creating records which seems incorrect.
Also, iOS supports additional fields which are not implemented in the type definition, mainly
Date (array)
Social profile (array)
Birthday (array - currently it's a single date but iOS supports different birthday types for Chinese, Hebrew etc)
Prefix
Phonetic first name
Pronunciation first name
Middle name
Phonetic middle name
Phonetic last name
Maiden name
Suffix
Nickname (although I assume this is the displayName property)
Job title
Department
Phonetic company name
Linked contacts (array, probably unnecessary feature but worth mentioning)
....potentially more but I think that's it
Perhaps the type definitions could support {key: string} definitions so that developers can implement additional fields as needed.
Alternatively (and probably the better solution) the definition could use some kind of typescript generics so that the definition can be extended? e.g
// pseudo code
export function addContact<T extends Contact>(contact: T): Promise<T>;
Also Birthday should probably not be required as a) records don't necessarily have them and b) currently the definition means that you HAVE to supply a fake birthday to create a record
Current Typescript
Contact
type follow this typeIn iOS I'm pretty sure all / most of the fields are
string | null (NSString | null)
properties however onlycompany
seems to have this definition, the majority being requiredstrings
. The outcome is that you need to provide a lot of empty string properties when creating records which seems incorrect.Also, iOS supports additional fields which are not implemented in the type definition, mainly
displayName
property)Perhaps the type definitions could support
{key: string}
definitions so that developers can implement additional fields as needed.Alternatively (and probably the better solution) the definition could use some kind of typescript generics so that the definition can be extended? e.g
Also
Birthday
should probably not be required as a) records don't necessarily have them and b) currently the definition means that you HAVE to supply a fake birthday to create a record