(feat) Add common typings for patient and person #1001
Conversation
chibongho
requested review from
mseaton,
mogoodrich,
denniskigen,
hadijahkyampeire and
ibacher
|
Size Change: -383 kB (-10.02%) 👏 Total Size: 3.44 MB
ℹ️ View Unchanged
|
| attributeType: OpenmrsResource; | ||
| display: string; | ||
| uuid: string; | ||
| value: string | number; |
There was a problem hiding this comment.
I don't think this is necessarily accurate. Can you check on this typing for value?
There was a problem hiding this comment.
you're right. This should be a string.
Yeah, most of these were from when we were making these types together in the service queues module months ago. |
|
One issue here is how we handle the difference between different representations. I'm not even necessarily thinking about custom representations, but, e.g., the default REF format for a person (which is returned in some circumstances): interface Person {
uuid: string;
display: string;
links: Array<{ rel: string; uri: string; resourceAlias?: string; }>;
} |
| deathDate: string; | ||
| causeOfDeath: Concept; |
There was a problem hiding this comment.
| deathDate: string; | |
| causeOfDeath: Concept; | |
| deathDate: string | null; | |
| causeOfDeath: Concept | null; |
| names: Array<PersonName>; | ||
| addresses: Array<PersonAddress>; | ||
| attributes: Array<PersonAttribute>; | ||
| birthtime: string; |
There was a problem hiding this comment.
| birthtime: string; | |
| birthtime: string | null; |
| birthtime: string; | ||
| deathdateEstimated: boolean; | ||
| causeOfDeathNonCoded: string; | ||
| links: Array<any>; |
There was a problem hiding this comment.
Links are always in this format:
export interface Link {
rel: string;
uri: string;
resourceAlias?: string;
}| links: Array<any>; | |
| links: Array<Link>; |
| dead: boolean; | ||
| deathDate: string; | ||
| causeOfDeath: Concept; | ||
| preferredName: PersonName; |
There was a problem hiding this comment.
Technically, this will be:
| preferredName: PersonName; | |
| preferredName: Pick<PersonName, 'uuid' | 'display' | 'links'>; |
Unless v=full is supplied.
| attributes: Array<PersonAttribute>; | ||
| birthtime: string; | ||
| deathdateEstimated: boolean; | ||
| causeOfDeathNonCoded: string; |
ibacher
changed the title
@mseaton these interfaces are definitely incomplete (for example, Patient has a
@ibacher Thanks for the suggestions. Unless a field's type can change based on the representation, this should be ok right? I think it'll still helpful to see what fields are available for each type while having the expectation that it's up to the implementor to verify that the fields they need are indeed there. |
I'm not really too concerned about that (it's fully possible with interface Person extends Pick<FullPerson, 'uuid' | 'display'>, Partial<Omit<FullPerson, 'uuid' | 'display'>> {}Because that would kind of force using something like: const patientName: string = patient.person.preferredName ?? patient.person.name?[0] ?? 'UNKNOWN'; |
I don't like having that forcing everywhere, but I think we can try it and remove it later if we want (easier to go from restrictive to loose, instead of vice versa). So how about something like this pattern? I think having every attribute being // this already exists:
export interface OpenmrsResource {
uuid: string;
display?: string;
[anythingElse: string]: any;
}
// we add this as the base type for almost everything
export interface OpenmrsResourceStrict {
uuid: string;
display?: string;
links?: Array<Link>;
}
interface Person extends OpenmrsResourceStrict {
// everything with a '?'
givenName?: string;
familyName?: string;
...
} |
I'm not hugely enamored with my own proposal, but I think that having the type system setup like that will help some of our community developers do the right thing. And, yeah, I'm happy with the pattern you suggest. |
chibongho
changed the title
| @@ -0,0 +1,5 @@ | |||
| import { type OpenmrsResource } from './openmrs-resource'; | |||
|
|
|||
| export interface Concept extends OpenmrsResource { | |||
There was a problem hiding this comment.
Does this need to be OpenmrsResourceStrict too? Should it have more properties?
There was a problem hiding this comment.
Not every type needed by the Patient type (directly or transitively) is completely typed yet. Specifically this Concept type and the User type below are just using OpenmrsResource as a flexible placeholder for now, while still being more correct than any. A completely typed type should extend OpenmrsResourceStrict instead. This convention should allow us to add more typings piecemeal.
ibacher
changed the title
ibacher
changed the title
|
Thanks @chibongho! I think this actually helps solve a long-standing problem we've had with types returned from APIs. |
Requirements
feat,fix, orchore, among others). See existing PR titles for inspiration.For changes to apps
If applicable
Summary
Screenshots
Related Issue
Other