fix(sdk): viem adapters accept wagmi's strongly-typed clients#127
fix(sdk): viem adapters accept wagmi's strongly-typed clients#127
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
👋 aelmanaa, thanks for creating this pull request! To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team. Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks! |
Coverage Report |
There was a problem hiding this comment.
I don't think these changes are needed, nor they improve the type safety of the fromViemClient function and friends
Rationale: parameters types in typescript functions (e.g. Abc in function foo(a: Abc) work as "constraints": they force the caller to pass values whose type match the required, and allow you to access properties of Abc inside the function;
When you convert that to a template, e.g. function foo<A extends Abc>(a: A), nothing changes from the caller nor the function perspective; it works virtually the same as the previous case, constraint-wise; The difference is: now, the CONCRETE type A can assume a different type than Abc, as long as it matches the constraint of being Abc or a specialization of it, and this CONCRETE type can then be used in other places, namely in other parameters constraints, in return type position, usually allowing further specializations, like conditional types, type mappings, etc.
Inside the function, you still can only access the properties which are common from Abc, as in the first, non-templated example; providing a default (<A extends Abc = Abc> doesn't change it, only assigns a default type to the type A (which can be Abc itself, or something else which matches the constraint) in case it can't be inferred automatically from the parameters.
In your case here, you're converting the function to a template generic, but not using the template variables for anything. So, it's effectively the same constraint as it was before. From this, it looks like you should be able to use the specialized types from wagmi with the current version exactly the same; again, template generics are only useful to capture the "concrete" types, and allow you to use them in other positions and/or map them to something else; constraint-wise, it should be the same, and the simpler types should be preferred. Unless you have another reason for converting this to the generics.
Use structural interfaces (ViemClientLike, ViemWalletClientLike) instead of strict viem generic types to solve type invariance issues with: - RainbowKit's getDefaultConfig() clients - Multi-chain configs mixing L1 and OP Stack chains (baseSepolia, optimism) - Wagmi's strongly-typed PublicClient/WalletClient The root cause was TypeScript type invariance: OP Stack chains have `type: "deposit"` transactions that L1 chains don't have, causing incompatible union types in viem's generic PublicClient<T, C>. Changes: - Add ViemClientLike and ViemWalletClientLike structural interfaces - Update fromViemClient() and viemWallet() to use structural types - Add comprehensive JSDoc with RainbowKit + OP Stack examples - Add unit tests for structural type acceptance - Add RainbowKit Integration section to docs No breaking changes - existing code continues to work.
aelmanaa
force-pushed
the
fix/viem-adapter-wagmi-types
branch
from
f080759 to
db496cb
Compare
3 participants
This pull request enhances the viem adapter support in the SDK, making it fully compatible with wagmi and RainbowKit clients, including OP Stack chains. The changes introduce new structural types (
ViemClientLike,ViemWalletClientLike) to ensure broad compatibility with various client implementations, improve runtime validation, and update documentation and tests to reflect these improvements.Viem Adapter Compatibility Improvements:
The SDK's
fromViemClientandviemWalletadapters now accept any viem-compatible client, including those from wagmi and RainbowKit, by using new structural types (ViemClientLike,ViemWalletClientLike). This resolves previous TypeScript incompatibilities and makes the SDK work seamlessly with OP Stack chains and multi-chain setups. [1] [2] [3] [4] [5] [6] [7] [8]Improved runtime validation in both
fromViemClientandviemWalletto ensure that required properties likechain.idandaccount.addressare present, providing clearer error messages for misconfigured clients. [1] [2] [3] [4]Documentation Updates:
docs/sdk/index.mdto include integration examples for wagmi and RainbowKit, demonstrating usage with OP Stack chains and multi-chain configurations.Testing Enhancements:
chainproperties. [1] [2]Changelog Update:
Version Bump: