Conversation
BundleMonNo change in files bundle size Unchanged groups (1)
Final result: ✅ View report in BundleMon website ➡️ |
| attribute: CommaDelimitedListOfUid; | ||
| filter: CommaDelimitedListOfAttributeFilter; | ||
| orgUnit: SemiColonDelimitedListOfUid; | ||
| ouMode: "SELECTED" | "CHILDREN" | "DESCENDANTS" | "ACCESSIBLE" | "CAPTURE" | "ALL"; |
There was a problem hiding this comment.
From the description of the PR:
Parameters orgUnit and orgUnitMode are removed and no longer supported in v42.
orgUnitMode should read ouMode in the description, right?
src/api/trackerTrackedEntities.ts
Outdated
| // https://docs.dhis2.org/en/develop/using-the-api/dhis-core-version-242/tracker.html#tracked-entity-collections | ||
| // This is a breaking change, but upgrade should be as easy as find and replace | ||
| orgUnits: CommaDelimitedListOfUid; | ||
| orgUnitMode: "SELECTED" | "CHILDREN" | "DESCENDANTS" | "ACCESSIBLE" | "CAPTURE" | "ALL"; |
There was a problem hiding this comment.
This would be a breaking change. With this change, we would no longer be able to use d2-api with DHIS2 versions earlier than 2.42 (or we would, but it will silently not work as expected)
We already have infrastructure to support different DHIS2 versions within the same codebase (src/VERSION/index.ts → D2Api extends D2ApiVersioned). Currently, this is only used to support different schemas (D2ModelSchemas), which is essential. But we have not used the infrastructure for anything else so far.
In this case, supporting multiple versions would require creating split implementations of tracker.ts, trackerTrackedEntities.ts, and trackerEnrollments.ts, ideally with some parent abstraction to avoid duplication.
This is something that has been on my mind for a while. Let me check with @adrianq whether we should go down this path, or instead change course and move to versioned d2-api releases.
There was a problem hiding this comment.
My bad I thought these parameters were added from v40 to v42, but they are valid only in v41 and v42, but not 40.
Also, are we going to validate the required parameters? They are different per version:
v40
https://play.im.dhis2.org/stable-2-40-11/api/tracker/trackedEntities -> "Either Program or Tracked entity type should be specified"
https://play.im.dhis2.org/stable-2-40-11/api/enrollments.json -> At least one organisation unit must be specified"
https://play.im.dhis2.org/stable-2-40-11/api/events.json -> no parameters required
v41
https://play.im.dhis2.org/stable-2-41-7/api/tracker/trackedEntities -> Either program, trackedEntityType or trackedEntities should be specified"
https://play.im.dhis2.org/stable-2-41-7/api/tracker/enrollments -> no parameters required
https://play.im.dhis2.org/stable-2-41-7/api/tracker/events -> no parameters required
v42
https://play.im.dhis2.org/stable-2-42-4/api/tracker/trackedEntities -> Either program, trackedEntityType or trackedEntities should be specified"
https://play.im.dhis2.org/stable-2-41-7/api/tracker/enrollments -> no parameters required
https://play.im.dhis2.org/stable-2-41-7/api/tracker/events -> no parameters required
There was a problem hiding this comment.
No problem, it's a good opportunity to re-think the approach to versioned d2-api, we'll get back to that.
About the filters: for the time being, let's keep it simple and make the type require only the props required by all versions. But we'll also get back to that after the decision.
src/api/trackerTrackedEntities.ts
Outdated
| // removing orgUnit and ouMode because they are being deprecated in v42 | ||
| // https://docs.dhis2.org/en/develop/using-the-api/dhis-core-version-242/tracker.html#tracked-entity-collections | ||
| // This is a breaking change, but upgrade should be as easy as find and replace | ||
| orgUnits: CommaDelimitedListOfUid; |
There was a problem hiding this comment.
From the docs, I extracted this (is it correct?):
- events: orgUnit, orgUnitMode
- enrollments: orgUnits, orgUnitMode
- trackedEntities: orgUnits, orgUnitMode
So probably it's a good time to do the same for the enrollments endpoint, right?
|
@eperedo So we have decided to take way 2: 1 branch per version in github + npm @eyeseetea/d2-api@DHISVERSION.x.y per version. On each branch:
|
…ance implementations
README.md
Outdated
|
|
||
| ```ts | ||
| import { D2Api } from "d2-api/2.36"; | ||
| import { D2Api } from "d2-api/2.42"; |
There was a problem hiding this comment.
We had an old reference here: d2-api -> @eyeseetea/d2-api
Also, what do you think if we allow the user to write import ... from " @eyeseetea/d2-api";, now that the branches are single-version? It's ok to keep the folder in the source, but some kind of re-export.
README.md
Outdated
| pageCount: 10; | ||
| total: 500; | ||
| }, | ||
| trackedEntities: [] |
There was a problem hiding this comment.
Minor, but just to veer in the right direction: as DHIS2 has a very stable demo database (Sierra Leone), I think it's nice to use real IDs and such in the examples. Here we could put a tracker program ID + pageSize=2 and have a real response shown.
package.json
Outdated
| "name": "@eyeseetea/d2-api", | ||
| "description": "Typed wrapper over DHIS2 API", | ||
| "version": "1.21.0-beta.3", | ||
| "version": "1.21.0-dhis2.42", |
There was a problem hiding this comment.
I've been thinking about the version schema. The problem with 1.21.0-dhis2.42 is that dhis2.42 is treated as a "prerelease" identifier, which semantically isn't what we have. Also, you can no longer use ^1.21.0 to specify a minimum API version.
An alternative would be to use the DHIS2 version as the major: 42.21.0.
I've seen this done in some npm packages. Maybe you've already discussed it with the PM.
There was a problem hiding this comment.
I think using 42.x.x is a good idea. The only downside is that it could be weird the big jump from 1.x.x to 42, but not really a big deal. What do you think @adrianq ?
There was a problem hiding this comment.
I agree with you guys - 42.x. is a good option
| @@ -159,10 +152,10 @@ export interface DataValue { | |||
| providedElsewhere?: boolean; | |||
There was a problem hiding this comment.
I passed the DHIS2 new tracker docs and our types to Claude and it found a bunch of things (missing props, renamed props, deprecated props. ex: attributeCc/attributeCos/assignedUser-vs-assignedUsers).
However, I don't think this PR is the place to do all this review, let's focus on the versioning and the orgUnit/orgUnitMode.
It's just to be aware that we can now use AI to review this kind of things, it's hard for a human not to miss something. At some point we will have tests, but it's not realistic to expect that they check every prop in the types.
|
We can change the name of the PR, something like "[42] Convert to single-version branch". Do we want to keep the orgUnit reference? Or maybe [v42] for the version, or the version at the end, many ways to do it. And we'll keep that style for future versioned PRs. |
…essary types for trackers
…om:EyeSeeTea/d2-api into feature/tracker-orgunitparams-42-869beeny2
tokland
left a comment
There was a problem hiding this comment.
Let's wait for @adrianq feedback on the versioning.
Otherwise, code looks good to me, I just got some warnings when running the linter. Additionally, something seems to be wrong in the infrastructure (as it signals errors on lines 0:0). Can you check it?
$ yarn lint
yarn run v1.22.22
$ eslint src --ext .js,.jsx,.ts,.tsx
/home/arnau/src/d2-api/src/api/appHub.ts
0:0 error Parsing error: Cannot read properties of undefined (reading 'map')
/home/arnau/src/d2-api/src/api/common.ts
0:0 error Parsing error: Cannot read properties of undefined (reading 'map')
/home/arnau/src/d2-api/src/api/trackerEnrollments.ts
4:10 error 'parseTrackerPager' is defined but never used @typescript-eslint/no-unused-vars
/home/arnau/src/d2-api/src/data/FetchHttpClientRepository.ts
170:57 error 'globalThis' is not defined no-undef
/home/arnau/src/d2-api/src/schemas/base.ts
0:0 error Parsing error: Cannot read properties of undefined (reading 'map')
/home/arnau/src/d2-api/src/utils/misc.ts
0:0 error Parsing error: Cannot read properties of undefined (reading 'map')
✖ 6 problems (6 errors, 0 warnings)
I've updated the eslint parser and plugin versions. Some other errors showed up so I fixed them as well. I've disabled the rule |
|
@eperedo We've discussed it with Adrian and decided to use old minor version as the new minor version. We won't bother with subversions of DHIS2 (42.x), we expect to target the latest stable . So 1.21 -> 42.21. I've pushed the change (with minor 22, the next release). Release to npm: 42.22.0-beta.1 |
📌 References
📝 Implementation
In v42 in order to filter tracker entities by org. units you need to pass the params
orgUnitsandorgUnitMode.https://docs.dhis2.org/en/develop/using-the-api/dhis-core-version-242/tracker.html#tracked-entity-collections
Parameters
orgUnitandouModeare removed and no longer supported in v42.📹 Screenshots/Screen capture
🔥 Notes to the tester
can you help me with a beta version please?