⚠️ No Changeset found

Latest commit: 9e20054

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.

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

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/zoo/wagmi/7Qeb6uMt1nPQf2MxhjhgCHsg3e8J
✅ Preview: https://wagmi-git-tmm-create-actions-zoo.vercel.app

@bpierre curious what you think of this. anything you would change or do differently?

@bpierre curious what you think of this. anything you would change or do differently?

Sorry for replying so late. It’s really cool, I like how we can now test these functions independently!

A few thoughts:

I was wondering if it could be a better idea to pick names like getBalance() rather than balanceAction() for the wagmi-core functions, and also have the config params directly rather than nested in { config: { … } }, to make wagmi-core feel more like an independant library.

But thinking more about it, these functions won’t be easy to use anyway, since they don’t carry any context and it (chain, provider) needs to be setup, so it’s probably not going to be an issue. And we could always add a class in the future, to keep the context around:

import { Wagmi } from 'wagmi-core'

// The Wagmi constructor would take the same options than the Provider
const wagmi = new Wagmi({ connectors: /* … */, autoConnect: true })

// Note 1: The Wagmi method names could follow the hooks, without the use- prefix.
// Note 2: The context is saved by Wagmi, no need to pass it to methods.
const balance = await wagmi.balance({ addressOrName: '0x…', token: '0x…' })

About the erronous state issue described in #140, I don’t really see a way to fix this without breaking compatibility:

• If we export a balanceAction() wrapper (with the connection context) rather than getBalance() to make it side effect free, it will break for consumers that were using it as a refetch() function.
• And if we make it a pure refetch() function, it will break for consumers that were using it as a data fetching function.

But with the React Query refactor, getBalance() is now a refetch() function accepting a config. From what I read (I haven’t tried to run this branch yet), we can still override the config passed to the hook frome here, but it doesn’t return anymore. Also, having watch: true now respects the latest config passed (rather than reverting to the hook params on the next update).

@tmm @jxom I was wondering if we shouldn’t simply remove getBalance() from the returned object in the React Query refactor, since we are breaking the compatibility anyway?

Migrating to the new version of wagmi would require consumers to either:

• Call refetch() if they want to force-refresh.
• Update the hook params if they want to update their hook configuration.
• Use balanceAction() from wagmi-core if they were using the promise returned by getBalance().

Yo @bpierre,

Yeah, I added getter fns (e.g. getBalance()) in addition to refetch just to try and keep the ability to imperatively invoke the hook functions, however thinking about it, it definitely would break compatibility with the current API, and might be a bit confusing since the config you pass to the getter fns also modify the cache. I reckon it might be a lot clearer to just remove this (as you suggested), and for the consumer to keep track of the hook parameters. I think this approach is more declarative, and would allow the consumer to think about side-effects more directly.

Good points! Let's remove this from the new version.