Point to 2.41 schemas

[anagperal]

📌 References

• Issue: Closes #869a4umgc Add schemas for version 41 and test User-Extended App with the new version

📝 Implementation

• point to 2.41 schemas
• fix errors when pointing to v2.41

📹 Screenshots/Screen capture

🔥 Testing

It needs new version of d2-api: EyeSeeTea/d2-api#178

To test it:

Go to that branch of d2-api:

yarn install
yarn build
cd build
yarn link

On this app:

yarn link "@eyeseetea/d2-api"

[ifoche]

Task linked: CU-869a4umgc Add schemas for version 41 and test User-Extended App with the new version

[tokland]

So it seems the upgrade to v41 was pretty painless - only the need for explicit access fields (which is a best practice, anyway). I guess it will be harder for v42, where the prop userCredentials has been removed.

Only, let's take the opportunity to refactor all the d2-api imports and make them pass though types/d2-api.ts (best practice):

$ grep -r '@eyeseetea/d2-api' src/ | grep -v types/d2-api
src/data/repositories/UserD2ApiRepository.ts:import { PatchOperation } from "@eyeseetea/d2-api/api/patch";
src/data/repositories/UserD2ApiRepository.ts:import { ErrorReport } from "@eyeseetea/d2-api/api/common";
src/data/D2ApiTracker.ts:import { TeiGetRequest } from "@eyeseetea/d2-api/api/trackedEntityInstances";
src/data/utils.ts:import { MetadataResponse } from "@eyeseetea/d2-api/api";
src/utils/futures.ts:import { CancelableResponse } from "@eyeseetea/d2-api/repositories/CancelableResponse";
src/domain/usecases/__tests__/SaveUserOrgUnitUseCase.spec.ts:import { MetadataResponse } from "@eyeseetea/d2-api/api";
src/domain/usecases/__tests__/CopyInUserUseCase.spec.ts:import { MetadataResponse } from "@eyeseetea/d2-api/api";

[anagperal]

So it seems the upgrade to v41 was pretty painless - only the need for explicit access fields (which is a best practice, anyway). I guess it will be harder for v42, where the prop userCredentials has been removed.

Only, let's take the opportunity to refactor all the d2-api imports and make them pass though types/d2-api.ts (best practice):

$ grep -r '@eyeseetea/d2-api' src/ | grep -v types/d2-api
src/data/repositories/UserD2ApiRepository.ts:import { PatchOperation } from "@eyeseetea/d2-api/api/patch";
src/data/repositories/UserD2ApiRepository.ts:import { ErrorReport } from "@eyeseetea/d2-api/api/common";
src/data/D2ApiTracker.ts:import { TeiGetRequest } from "@eyeseetea/d2-api/api/trackedEntityInstances";
src/data/utils.ts:import { MetadataResponse } from "@eyeseetea/d2-api/api";
src/utils/futures.ts:import { CancelableResponse } from "@eyeseetea/d2-api/repositories/CancelableResponse";
src/domain/usecases/__tests__/SaveUserOrgUnitUseCase.spec.ts:import { MetadataResponse } from "@eyeseetea/d2-api/api";
src/domain/usecases/__tests__/CopyInUserUseCase.spec.ts:import { MetadataResponse } from "@eyeseetea/d2-api/api";

Done! Would be ok to expose in @eyeseetea/d2-api/api/index also "common", "patch" and "trackedEntityInstances" to don't do??:

export type { TeiGetRequest } from "@eyeseetea/d2-api/api/trackedEntityInstances";
export type { PatchOperation } from "@eyeseetea/d2-api/api/patch";
export type { ErrorReport } from "@eyeseetea/d2-api/api/common";

[tokland]

All good!

[tokland]

Done! Would be ok to expose in @eyeseetea/d2-api/api/index also "common", "patch" and "trackedEntityInstances" to don't do??

Yes! Ideally, all useful public interface should be exported so we can write import { Something } from "@eyeseetea/d2-api". This way we can change the internal structure without breaking the apps.

[anagperal]

Ask to Codex to review PR:

• src/types/d2-api.ts hardcodes the API version in import and export paths, creating maintenance overhead when upgrading DHIS2 versions
• src/utils/tests.tsx suppresses type checking with @ts-ignore, leaving test fixtures untyped and potentially masking errors
• src/data/D2ApiTracker.ts repeats new Date().getTime() for ID generation, risking inconsistent timestamps and reducing readability
• The helper getD2APiFromInstance in src/utils/d2-api.ts is misnamed (APi), which can confuse consumers and hinder IDE search tools

They are tasks not related to this PR or this task, but as they are, but since they are very small tasks, I have done them in this PR.

The first task about hardcoded version of d2-api, Codex has done this code. In my opinion, it is adding incorrect types, and I'm not sure if it makes sense to set the API version from the env variables, since the code is adapted to a specific d2-api version.