fix(react): out-of-sync persisted contract results

[jxom]

Fixes #460

Description

There is an interesting bug where persisted useContractRead struct results would be out of sync with the ethers contract Result. This is because the ethers Result currently doesn't serialize properly with our serialize function. I first attempted to try fix this in our serialize/deserialize functions to try get it to persist into our storage, however, after doing that, I then realised that React Query also doesn't cater for this data structure in their data comparison functions.

In this proposed fix, I ended up just checking to see if the result returned from RQ is in an out-of-sync state, and if it is, it will use the contract interface to parse it back into an ethers contract Result.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6840669

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
wagmi	✅ Ready (Inspect)	Visit Preview	Jun 6, 2022 at 2:42PM (UTC)

[tmm]

Nice job hunting this down.

[tmm]

Looks great! Nice job on getting RQ update in.

[0xfffxfff]

@jxom Since updating to wagmi@0.4.10 I'm getting errors with all my instances of useContractRead:

next-dev.js?3515:25 TypeError: Cannot add property null, object is not extensible
    at Function.assign (<anonymous>)
    at parseContractResult (wagmi.esm.js?20d3:73:1)
    at Object.select (wagmi.esm.js?20d3:1275:1)
    at QueryObserver.createResult (queryObserver.mjs?eb18:273:1)
    at QueryObserver.getOptimisticResult (queryObserver.mjs?eb18:92:1)
    at useQuery (wagmi.esm.js?20d3:365:5)
    at useContractRead (wagmi.esm.js?20d3:1272:1)

For now I'm reverting to 0.4.7, our previous version. Any idea what this could be caused by?

npm view wagmi dependencies
{
  '@coinbase/wallet-sdk': '^3.2.0',
  '@wagmi/core': '^0.3.7',
  '@walletconnect/ethereum-provider': '^1.7.8',
  'react-query': '^4.0.0-beta.23',
  'use-sync-external-store': '^1.1.0'
}

[jxom]

@0xfffxfff would you be able to provide me with a minimal reproducible example via a CodeSandbox or something?
Thanks for spotting this too!

[0xfffxfff]

@jxom We're in the middle of a release right now. I can try spinning one up on Monday. 👍

[0xfffxfff]

@jxom Just to give you an idea where this happens:

const balanceOf = useKubboPartsRead('balanceOf', { args: account?.data?.address, enabled: Boolean(account?.data?.address), watch: true })

where useKubboPartsRead is a hook that wraps useContractRead

export const useKubboPartsRead = (
  functionName: string, config?: Parameters<typeof useContractRead>[2]
) => {
  const network = useNetwork()
  const contract = Contracts.KubboParts[network?.activeChain?.id || chain.mainnet.id];
  return useContractRead(contract, functionName, config)
}

Entirely possible that my use of the hook is causing this.

Edit: This is how we include our contracts

KubboParts[chain.mainnet.id] = {
  addressOrName: KubboPartsABI.address,
  contractInterface: KubboPartsABI.abi as ContractInterface,
} as UseContractConfig

[jxom]

Thanks! I'll do some digging.

[jxom]

@0xfffxfff – I'm assuming the return type of this method was a tuple?

There is a fix here: #566

[0xfffxfff]

Thanks @jxom! This fixed it.

I'm assuming the return type of this method was a tuple?

It was an array of uint256. Funnily enough, I had to change a useEffect dependency from this:

  }, [
   tokensOf.data,
   ...
 ]);

to this:

 }, [
  tokensOf.data?.reduce((c,i) => c+i?.toString(),''),
  ...
]);

I'm guessing the reason is that it's no longer receiving the same array but rather a newly constructed one on each call? In any case, with this in place everything's now properly chugging along 👍