Refactoring to use new SDK under the hood

[Dominic-Marcelino]

The nuxt-module hasn't been relying on the directus SDK in order to do things the nuxt-way. With the new SDK coming soon (currently in beta) I'm wondering if it wouldn't make sense to re-evaluate this.

The new SDK has better types support and relies on fetch instead of axios.

With building on top of the SDK developer would have benetifs like:

• More consistend DX between Nuxt and non-Nuxt Projects communicating with Directus
• Feature parity (the module is still missing a buch of functions like file-upload, getFileByID)
• Tree-shakable features (only bundle what you need)

Looking forward to your feedback

[casualmatt]

I can't speak for @Intevel, but the idea, in general, is that if we migrate from $fetch (unJS ofetch) we do it for useFetch or useAsyncData to better integrate with Nuxt Multiple Environment support, which will not grant the support for fetch, and could introduce edge cases.

[casualmatt]

And you can already expose Directus SDK as a plugin yourself if you want the whole SDK experience, but as for Strapi the module is made to fit the Nuxt ecosystem.

[Dominic-Marcelino]

but the idea, in general, is that if we migrate from $fetch (unJS ofetch) we do it for useFetch or useAsyncData

useFetch and useAsyncData both use a caching system, which is not wished in all use-cases. I assume that's why this module also uses the pure $fetch.

If it's only about fetch, it would be possible to override the fetch object. Right now it's only possible for the global fetch, but I'm pretty sure the team is open for discussion in order to pass a custom fetch instance / wrapper.
https://discord.com/channels/725371605378924594/1121094628037361768/1121114471423823953

[casualmatt]

I need to check but I don't think that the 2 composables introduce any form of caching, they ar just optimized for various rendering mode, so that request are not repeates on hydration.

In any case we didn't proceed in migrating to useFetch because of braking changes that will introduce.

[sandros94]

Yes, it is mainly for hydration consistency and basic-state management of the fetched data. But more importantly useFetch is basically useAsync($fetch).

If fact this is how I use it when I need consistency in hydration or reduce at maximum the api calls:

const { data: VARIABLE-NAME } = await useAsyncData('KEY-NAME', () =>
  getItems({
    [...]
  })
)

This way in a subsequent page (or component) that needs the same data I could just do:

const VARIABLE-NAME = useNuxtData('KEY-NAME')

Or even use it like a cache to preview something for that data that needs frequents updates even on client side.

[casualmatt]

That is what we suggest currently, but we already implement $fetch instead of fetch to improve support for different rendering modes.
@Intevel and I are working to understand how the new SDK, could be implemented in Nuxt with Nuxt UseFetch or UseAsyncData to support all rendering modes better and not have duplicate requests.

But this could take some time; for now, we still support the current module, and a new update should come in a few days.

[Intevel]

@Dominic-Marcelino Im looking forward to maybe rewrite this module using the new SDK & the powerfull features provided by Nuxt.

We will track this process in this discussion.

[Intevel]

Im currently trying something out with the new SDK, you can check https://github.com/intevel/nuxt-directus/tree/dev branch. And may contribute if you want, we check if the SDK suits. @Dominic-Marcelino

[sandros94]

I would like to help, but I feel a little bit lost since this is only the third module I work on. To start with I'm reading the @directus/sdk documentation.

How are you planning to do this? Looking at the code I imagine that you are exposing the full sdk via useDirectus composable and then build a set of other composables with the same scopes as the currently available ones? (eg. I see useDirectusAuth and useDirectusCookie)

[Intevel]

The idea is to wrap some of the functions of the SDK (as well as Auth) into own composables to continue using Nuxt features like useCookie.

[sandros94]

The idea is to wrap some of the functions of the SDK (as well as Auth) into own composables to continue using Nuxt features like useCookie.

Speaking of useCookie: since there have been recent changes (nuxt 3.6.0 release that included some state management for it), alongside with other (potentially useful) functionalities, would you consider to bump the nuxt version of the module and the related minimum requirement? Or are you aiming to make the module fully retro compatible with all nuxt 3 versions?

EDIT: actually I don't fully know if using a higher version of nuxt to create the module would result into the need of bumping the minimum requirement of nuxt version where the module gets used

[sandros94]

@Intevel idk about you but I'm loving this sdk (never used the old one).

It is so simple to use and I'll be happy to try my best and rewrite the current nuxt-directus module with it.
I'm opening a draft PR so you could check the progress (already made the auth work and optimized the cookies a bit), I'll much appreciate your opinion.

[Dominic-Marcelino]

I saw that some initial work has been done. Has there been any outcome weather the approach is promising and will be continued?

[Intevel]

@Dominic-Marcelino Thats right, and that would be exactly the reasons to use the SDK, many features are not yet implemented in this module, but in the SDK. Types would always have to be maintained here, and ....

My thought in the current is to use the SDK and implement auth and other core features myself or in combination with the SDK and Nuxt features.

[Dominic-Marcelino]

FYI: there's an open PR from the team to configure fetch: directus/directus#19606

[rijkvanzanten]

Closed PR now 😄 (It'll ship today!)

[sandros94]

Closed PR now 😄 (It'll ship today!)

Oh man, this opens up so many things to do!

[Intevel]

Looks nice, thanks.

[sandros94]

Just as an update, I opened up a new discussion to track the current state of the rewrite at #215. If any of you have considerations on the topic or want to follow the progress I encourage you to go and comment or subscribe to that discussion! 😁

[Dominic-Marcelino]

Thanks for your great work! 🎉

[casualmatt]

--> #271

nuxt-directus-next is EOL.

We will start to work on a v6 based on Nuxt First Approach