I am facing a situation where I need to create an API-call, but it should not be fired until the component is mounted.

That's what I got so far:

onMounted(async() => {
    const {
        data,
        refresh,
        pending,
        error
    } = await useApi(`/profile/${$auth.user.profile.sid}`, null, ['data']);

});

const computedWaiting = computed<boolean>(() => {
    return pending.value === true;
});

Now the problem is, that the computedWaiting throws an error, as pending is not defined. So I would need to destruct the useApi-response, which is basically an https://github.com/unjs/ohmyfetch-result.

This is the useApi-method (taken from this GitHub-Issue: https://github.com/nuxt/framework/discussions/4504):

import {FetchOptions} from "ohmyfetch";

const csrf_cookie: string = "XSRF-TOKEN";

/**
 * Return the cookies needed by "Sanctum", browser will handle them automatically.
 */
export const useFetchCookies = async () => {

    await $fetch.raw("/backend/sanctum/csrf-cookie", {
        credentials: "include" // Allow browser to handle cookies
    });
};

/**
 * Api call using nuxt `useFetch`
 *
 * @see {@link https://github.com/unjs/ohmyfetch#readme} ~ ohmyfetch Docs
 * @param url
 * @param options
 * @param pick
 */
export const useApi = async (url: string, options?: FetchOptions, pick?: any) => {

    // First we verify if the `xsrf-token` is present on the browser cookies
    let token = useCookie(csrf_cookie)?.value;

    if (!token) {
        // If not present we will re fetch all cookies, the browser will
        // handle them automatically so we don't need to do anything
        await useFetchCookies();

        // Load the new token value to use it in the `headers`
        token = useCookie(csrf_cookie).value;
    }

    // Here we will create a default set of headers for every request
    // if present we will also spread the `headers` set by the user
    // then we will delete them to avoid collision in next spread
    const headers: HeadersInit = {
        Accept: "application/json",
        "Cache-Control": "no-cache",
        "X-XSRF-TOKEN": token,
        ...options?.headers
    };

    // At this point all the `headers` passed by the user where correctly
    // set in the defaults, now we will spread `options` to remove the
    // `headers` attribute so we don't spread it again in `useFetch`
    const opts: FetchOptions = options ? (({headers, ...opts}) => opts)(options) : null;

    return useLazyFetch(`/backend/api${url}`, {
        server: false,
        credentials: "include", // Allow browser to handle cookies
        headers,
        ...opts,
        pick: pick
    });

};

It could be helpful to know that useFetch comes from https://v3.nuxtjs.org/guide/features/data-fetching, which basically uses ohmyfetch as a composable itself: https://github.com/nuxt/framework/blob/46c656c4b85c3622b99a7c4f6a01f5b11c830be6/packages/nuxt/src/app/composables/fetch.ts#L18-L59

So how can I expose the data, refresh, pending and error most elegantly after onMounted?

CodePudding user response：

It's incorrect to call a composable in onMounted without a specific purpose. Vue composables are generally to be used directly in setup function, so a result could be accessed immediately. Whether it's possible to use them in other places depends on their implementation.

In case a composable involves asynchronous side effects, it's supposed to return reactive result, returning a promise of a result would limit its uses. useFetch is Nuxt composable that returns a promise and seems to be intended for the use in Nuxt lifecycle hooks, while useLazyFetch is generic Vue composable.

This is shown in the usage of useLazyFetch, properties of a result are refs and so are reactive. In case it's wrapped with custom composable, a result from useLazyFetch needs to be composed by means of Vue composition API, e.g. pending should reflect the overall state of a current operation.

Both useFetchCookies and useApi need to be changed to be conventional composables.

export const useToken = () => {
    const data = ref(null);
    const error = ref(null);
    const pending = ref(true);
    const token = useCookie(csrf_cookie).value;

    if (!token) {
      const result = useLazyFetch("/backend/sanctum/csrf-cookie", {
        credentials: "include" 
      });

      watch(result.pending, (val) => {
        pending.value = val;

        if (!val)
          data.value = useCookie(csrf_cookie).value;
      });

      watch(result.error, (val) => {
        error.value = val;
      });
    } else {
      pending.value = false;
      data.value = useCookie(csrf_cookie).value;
    }

    return { data, error, pending };
};

export const useApi = (url: string, options?: FetchOptions, pick?: any) => {
    const data = ref(null);
    const error = ref(null);
    const pending = ref(true);
    const refresh = () => fetchResult.value?.refresh();
    
    const fetchResultRef = ref(null);

    const tokenResult = useToken();

      watch(tokenResult.data, (token) => {
        if (!token)
          return;

        const headers = ...;
        const opts = ...;    
        fetchResultRef.value = useLazyFetch(`/backend/api${url}`, {
            server: false,
            credentials: "include",
            headers,
            ...opts,
            pick: pick
        });
      });

      watch([
        tokenResult.pending,
        () => fetchResultRef.value?.pending ?? true
      ], ([tokenPending, fetchPending]) => {
        pending.value = tokenPending || fetchPending;
      });

      watch([
        tokenResult.error,
        () => fetchResultRef.value?.error ?? null
      ], ([tokenError, fetchError]) => {
        error.value = tokenError || fetchError;
      });

      watch(() => fetchResultRef.value?.data ?? null, (value) => {
        data.value = value;
      });

      return { data, error, pending, refresh };
};

Notice that in this implementation useCookie result is reactive but the reactivity is discarded, and so refresh in useToken remains unused. useLazyFetch does a request immediately, despite the name, so its call needs to be postponed until headers are available. It can be called asynchronously after setup function, this is allowed by its implementation.