Navigation fails when using nested Colada Loaders

[penpenpng]

Version

5.0.3

Reproduction link

https://github.com/penpenpng/colada-loader-bug-repro

Steps to reproduce

npm install
npm run dev

And click the case1 link.

What is expected?

I am looking for one of the following:

• If my implementation is invalid, a recommended way to achieve sequential, individually cached API calls using Data Loaders.
• If the documentation regarding Nested Loaders is misleading, an update to the docs.
• If this is a bug in the Colada Loader implementation, a fix for the context loss.

What is actually happening?

Navigation fails with the warning [Vue warn]: inject() can only be used inside setup() or functional components. when using nested Colada Loaders.

---

In my application, I need to call two APIs during page initialization. The second call depends on the result of the first one, so they must be executed sequentially. I also want these API calls to be cached individually by Pinia Colada.

I defined the loaders as follows:

// Dummy APIs
const getNext = async (x: number | string) => {
  return new Promise<number>((resolve) => {
    setTimeout(() => {
      resolve(Number(x) + 1);
    }, 100);
  });
};

const NEXT_QUERY_KEY = (x: number | string) => ["next", x];

// Data Loaders
export const useNextLoader = defineColadaLoader({
  key: (route) => NEXT_QUERY_KEY(route.params.value),
  query: (route) => getNext(route.params.value),
});

export const useNextNextLoader = defineBasicLoader(async () => {
  const next = await useNextLoader();

  const useNextNextLoader = defineColadaLoader({
    key: () => NEXT_QUERY_KEY(next),
    query: () => getNext(next),
  });

  return useNextNextLoader();
});

I assumed this was valid based on the Nested Loader constraints, and I believe defineColadaLoader shouldn't be context-dependent. However, this causes the inject() warning, likely because the Colada Loader cannot find the currentContext.

Interestingly, wrapping the first loader with withLoaderContext() seems to resolve the issue, even though the documentation suggests it shouldn't be necessary in this case:

-  const next = await useNextLoader();
+  const next = await withLoaderContext(useNextLoader());

[posva]

Defining a loader inside of a loader is def not supported (it could work in some scenarios though)

On a first look this looks like a loss of the context in pinia colada loader, I will investigate further.

Why are you mixing colada and basic loaders though? The only use case would be async combination of both data

[penpenpng]

Defining a loader inside of a loader is def not supported

Thank you for the clarification. In that case, could you please advise how what I am trying to achieve should be written?

Why are you mixing colada and basic loaders though?

This approach was the only reasonable way I could think of to express sequential API calls with dependencies between them. If there is a recommended way to achieve this using only Colada Loader, I would be happy to adopt that approach.

[posva]

Fixed in fce5d1e, there was a bug with context restoration

You can do something like

const useNextNextLoader = defineColadaLoader(ROUTE_NAME, {
  key: (to) => [ROUTE_NAME, ...NEXT_QUERY_KEY(TODO)],
  query: async (to, { signal }) => {
  const next = await useNextLoader();
  return getNext(next)
  },
});

the issue is that the key must be definable before and without async, ideally it should come from to. I might want to introduce a different syntax that allows passing parameters but that would go against the point of data loaders: they should be callable just by knowing the navigation. However, in your case this still technically holds tru since the parameter comes from another loader. I will add it to the project todos

[penpenpng]

Thank you for the advice and for considering this!