How do you handle hooks that depend on data from another hook?

[eshlox]

A simple example. Let's say I want to call getReserves on pair address.

const pairArgs = React.useMemo(() => {
  return [tokenA, tokenB];
}, [tokenA, tokenB]);
  
const [{ data: pairAddress }] = useContractRead(
  {
    addressOrName: ADDRESSES.FACTORY,
    contractInterface: ABIS.FACTORY,
  },
  "getPair",
  {
    args: pairArgs,
    skip: !tokenA || !tokenB
  }
);

To call getReserves, I need the pair's address.

const [{ data: reserves }] = useContractRead(
  {
    addressOrName: pairAddress,
    contractInterface: ABIS.PAIR,
  },
  "getReserves",
  {
    skip: !pairAddress
  }
);

The skip parameter is useful when arguments are not ready, but what about addressOrName?

The addressOrName requires a string. The hook returns Result | undefined.

Type 'Result | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'.

I can't pass undefined (addressOrName) or an empty string (addressOrName || "") because it throws an error:

Error: invalid contract address or ENS name (argument="addressOrName", value=undefined, code=INVALID_ARGUMENT, version=contracts/5.5.0)

Error: resolver or addr is not configured for ENS name (argument="name", value="", code=INVALID_ARGUMENT, version=contracts/5.5.0)

The only option that works is to use the type assertion and pass any correct address if the expected pair address is undefined.

const [{ data: reserves }] = useContractRead(
  {
    addressOrName: pairAddress ? (pairAddress as unknown as string) : ADDRESSES.CORRECT_ADDRESS,
    contractInterface: ABIS.PAIR,
  },
  "getReserves",
  {
    skip: !pairAddress
   }
);

Is there a better way?

[bpierre]

It could be nice if could make it so that parameters passed to wagmi hook could be either:

• The accepted value type (as it currently is).
• A React-Query-like result object, resolving to this same value type.

It would allow to do this in this kind of situations:

const pairResult = useContractRead(
  { addressOrName: ADDRESSES.FACTORY, contractInterface: ABIS.FACTORY },
  "getPair",
  { args: pairArgs }
)

const reservesResult = useContractRead(
  { addressOrName: pairResult, contractInterface: ABIS.PAIR },
  "getReserves"
)

The rules could be as follows:

• reservesResult starts by being in a loading state, as normal − except it waits for all its result-like parameters to resolve before actually loading anything (kind of like using skip, except it will do it automatically for you).
• If pairResult errors, reservesResult resolves to an error based on it but could also provide more context, e.g. “A result-like parameter of useContractRead() failed: ”.
• If pairResult resolves, reservesResult starts to load internally, as it would do for hooks using parameters that are not result-like objects.
• If several result-like object params exist, the hook waits for all of them to resolve before doing anything. The first one to error stops everything.

Note that it would accept any result-like object, which means that it would be compatible with any library returning objects following the React Query structure.

---

@eshlox For a more immediate solution to your problem: do you have the possibility to split it in two components? That way you could only load the component containing the second hook when the first one is loaded:

function ComponentA() {
  const pairArgs = useMemo(() => [tokenA, tokenB], [tokenA, tokenB]);

  const [{ data: pairAddress }] = useContractRead(
    { addressOrName: ADDRESSES.FACTORY, contractInterface: ABIS.FACTORY },
    "getPair",
    { args: pairArgs, skip: !tokenA || !tokenB }
  );

  return pairAddress ? <ComponentB pairAddress={pairAddress} /> : null
}

function ComponentB({ addressOrName }) {
  const [{ data: reserves }] = useContractRead(
    { addressOrName, contractInterface: ABIS.PAIR },
    "getReserves"
  );

  // …
}

[eshlox]

@bpierre Thanks for the answer.

That's what I'm doing now in some cases. I have a separate component to get the pair address, and when it's ready, it renders the rest of the page, but it's a kind of workaround. 😉 The getReserves is not the only operation that requires a "dynamic" addressOrName value (which may be undefined for a while), at least in my case. When I want to use approve or allowance calls, I have to provide a token address, which is not always a static value (for example, a user has to select a token from the list first).

@tmm maybe it's something to think about when making changes related to #85? 🤔

[tmm]

Exactly. Rolling out some changes along these lines soon.