asyncDataOptions type doesn't accept watch: false

[rigtigeEmil]

Nuxt's useFetch accepts watch?: MultiWatchSources | false (docs), which is the idiomatic way to disable auto-refetching on reactive param changes.

However, asyncDataOptions is typed as AsyncDataOptions<...> (from nuxt/app), which only has watch?: MultiWatchSources — missing | false. Passing watch: false produces:

Type 'boolean' is not assignable to type '(object | WatchSource<unknown>)[]'

This is because the | false variant lives on Nuxt's UseFetchOptions type but not on AsyncDataOptions, and hey-api uses the latter.

Suggested fix: Extend the type to accept false:

asyncDataOptions?: AsyncDataOptions<...> & { watch?: false };

Workaround: watch: [] compiles and has the same runtime effect, but is less idiomatic.

[mrlubos]

@rigtigeEmil I'm starting to think the Nuxt implementation is wrong, based on the number of bugs. Do you think it needs an overhaul?

[rigtigeEmil]

@mrlubos Do you have insight into the usage of the Nuxt implementation? I've started using it "for real" recently, which is why I've been bumping into some things, but if I just happen to be one of the first adopters, I'd guess that's expected.

I think the biggest value is aligning the API's from Nuxt with the wrapper exposed, but that's (mostly) a minor detail, but I would hazard a guess that it'll slow adoption, if it's something new for people to learn. Getting the reactivity things fixed was the biggest deal for me, along with the missing options for the various composables.

Let me know if you need more input, but I'm happy to open issues/PR's, when I run into issues like these. The quick turnaround on them is much appreciated 🫶

[mrlubos]

@rigtigeEmil I don't track detailed numbers but based on the module, I'd expect it to be very low compared to the rest. That's why I don't dedicate much time to Nuxt. At the same time, if the implementation isn't good, it won't have a lot of usage. It's a self-fulfilling prophecy. I'm open to all feedback, feel free to suggest improvements. I know there is a handful of people who do use Nuxt/Vue, they'd probably have an opinion if the proposed changes were more drastic

[rigtigeEmil]

@mrlubos yeah adoption and quality will obviously go hand-in-hand.
I'll open issues when there are discrepancies from "the Nuxt way" and this library, but I do find that most the things, apart from #3129 and #3360, are mostly about aligning to be as close to Nuxt as possible, which, to my understanding, is what we want to achieve.

If you have time to dedicate to it, I think this would be worthwhile dedicating some time to, checking if there are any other "obvious" misalignments, but again, not something I'd consider a blocker at all 🤷

[mrlubos]

@rigtigeEmil If the pull requests continue to look as they did, it's very easy to dedicate time to!