Improve TypeScript experience in the SDK

[dstoyanoff]

Preflight Checklist

• I have completed all Troubleshooting Steps.
• I'm on the latest version of Directus.
• There's no other issue that already describes my problem.

Describe the Bug

The types in the SDK are not optional and can be improved.

Collections querying

At the moment, the type of the collection (C) accepts a pure string and returns a collection, based on that string, as defined in the instance type (T):

singleton<C extends string, I = TypeOf<T, C>>(collection: C): ISingleton<I>;
items<C extends string, I = TypeOf<T, C>>(collection: C): IItems<I>;

While this works well for return type, it doesn't have an autocomplete for the collection names. This has an easy fix:

singleton<C extends keyof T, I = TypeOf<T, C>>(collection: C): ISingleton<I>;
items<C extends keyof T, I = TypeOf<T, C>>(collection: C): IItems<I>;

Partials

OneItem and ManyItems["data"] are both defined as Partials, which I believe is due to the fields selection that's available in the SDK. However, this makes the usage of the library very difficult for the end user. Perhaps a better way would be to look at the fields and decide on the type. Not sure of the proper implementation, but should be possible (see the next point for similar solution).

Fields filter

Fields are prompted properly today. However, as of TypeScript 4.1, there is now support for Template Literal Types, so we can also describe nested fields safely. Here is an article about it - https://newbedev.com/typescript-deep-keyof-of-a-nested-object

Side note: Maybe we could also create a d.ts generator to generate definitions from a running Directus Instance 😛

What version of Directus are you using?

rc.92

[rijkvanzanten]

Side note: Maybe we could also create a d.ts generator to generate definitions from a running Directus Instance 😛

Totally! We should add a /specs/ts endpoint next to the existing graphql / openapi ones 🙂

(@joelbqz)

[fabian-hiller]

Hi all, is there any update or workarounds on "Partials" and "Fields filter"? I am facing exactly the described problem that each field could also be "undefined" although I know that it is not. This makes working with the SDK exhausting, as I have to either cast the types or write an if-statement before each use so that TypeScript doesn't throw errors.

[joselcvarela]

This is on our backlog but we didn't have the time yet to finalise.

If you have an idea of how can we solve this, we are open for a PR 👍

[fabian-hiller]

Hey @joselcvarela, thank you for your answer. Unfortunately, I can't accommodate that in terms of time. I will support you in other ways this year.

[FINDarkside]

I think it would require some major changes to the sdk to make it type safe. The current way of passing one magic string means that ts can't help you at all at writing it and cannot infer any return types from it. If the api was more like mongodb api or similar, it could be typed properly.

For example if you had something like

fields: {
  translations: '*',
}

instead of fields: 'translations.*' you could type it in a way that you never need any error prone typecasting.

[rijkvanzanten]

Heya! Thank you for taking the time to submit this request!

It has been over 90 days, and this discussion has not received at least 15 votes from the community. This means that we don't feel like there's enough community interest to warrant further R&D into this topic at this time. 🧊

This request will now be closed to keep our discussions tidy. Please reach out if you have any questions!

For more information, see our Feature Request Process.