Start a new pull request in StackBlitz Codeflow.

• nuxt-starter-haznex (Open reproduction)

Is there a reason you don't want to use $fetch?

we are using @nuxtjs/strapi to fetch the data from strapi, and according to their specifications we should use useAsyncData to enable SSR. We suppose we cannot use $fetch in combination with @nuxtjs/strapi

See this documentation: https://strapi.nuxtjs.org/advanced#async-data

Just use findOne without useAsyncData in the middleware

does that work with SSR and payload extraction?

And the new shared async data cannot be used this way: https://nuxt.com/blog/v3-10?ref=dailydev

I have the same issue with middleware in lucia-auth (https://github.com/lucia-auth/examples/blob/main/nuxt/username-and-password/middleware/auth.global.ts)

Confirming that I have the same issue with lucia-auth middleware.

Is there a reason you don't want to use $fetch?

@danielroe
According to the dollarfetch documentation, that would cause the data to be loaded twice - unless it works different in the middleware?

Also, the warning states, that the component would be already mounted - while the middleware should be independant of components? Is that just a confusing warning message then?

@BBoehm It really depends. But yes, every time you call $fetch the request will be made fresh. You could use useState to avoid that. Or directly access and manipulate nuxtApp.payload. I wouldn't call useAsyncData on each route navigation though... That will perform additional requests every time you change page, even though it won't do so on initial load.

nuxtApp.payload

To prevent repeated requests, you can use nuxt.payload or useState.

In my case, I use pinia, which stores the data. To prevent a repeat request, I check if my storage is full and if the ID matches. If the storage is empty, then I make a request, if the id does not match, then I make a request (if it matches, then there will be no request). The same can be done using user State.

I created a discussion about this

import type { StateTree } from "pinia";

export default defineNuxtRouteMiddleware(async (to, from) => {
    const {payload}=useNuxtApp()
    const { Conversation } = storeToRefs(useChat());
    const { getDialog } = useChat();
    let state = payload.pinia as Record<string, StateTree>;
// inital load, check object or check id
    if (
        Object.keys(state.chat.Conversation).length < 1 ||
        to.params.id !== state.chat.Conversation.id.toString()
    ) {
        await getDialog(<string>to.params.slug, <string>to.params.id);
    }

//404
    if (Object.keys(Conversation.value).length < 1) {
        return abortNavigation();
    }
});

Confirming that I have the same issue with lucia-auth middleware.

I managed to fix it using useRequestFetch() instead.
#23423

We are experiencing the same warning: Component is already mounted, please use $fetch instead. In our project we are using global route middleware to check some main attributes and user data (both fetched from our internal api using useFetch). There is no worry for additional requests as this should be caught by the getCachedData option, unless you intentionally change the usage like we do (custom useFetch adding ttl and force reload to the getCachedData function).

I couldn't find any reason reading through this issue why useFetch shouldn't or can't be used in route middleware (it even states it can be used in the documentation: 'meant to be called directly in a setup function, plugin, or route middleware'), so in my opinion the warning should not include the component instance check it does right now.

To me, the warning in useAsyncData targets a specific use case. Our use case is not about fetching data that can be replaced using $fetch. According to the recommendations, useAsyncData should be used when useState cannot be used, which is precisely the case we're facing. While you ccertainly can work around the async issue of useState the boilerplate for each instance of this is quite large, which useAsyncData handles beautifully for you.
The warning is valid for situations where $fetch can be used, this does not apply to our case and works as intended.

Since the $fetch scenario is probably the most common one, either a slight revision to better detect this issue is in order, or an option to turn off this warning should be provided, as it can be quite cumbersome.