Viem

Bounties

Technowatermelon. Elder Millenial. Building Farcaster. 

nf.td/varun

Here's a PR. Took the opportunity to migrate to viem's new tree-shaking pattern as well. 🫡

https://github.com/farcasterxyz/hub-monorepo/pull/2181

viem’s extreme type safety is awesome if you know the exact shape of all your parameters the moment you call each client action.

As soon as you want to derive your own composable helper functions with partial or variable parameters… the TypeScript generics get complicated, fast. 😅

/frontend dev・founder/decentralized data wrangler /blockhead・ritual.net・UI/UX abstractionist・DeFi/web3 builder・dropout・24・prev /dydx・x.com/darryl__yeo

So I was upgrading Hubble to @viem v2.0, and some wrapper class instances were giving *super gnarly* deeply-nested TypeScript errors in some unexpected places.

Of course, viem's internal conditional types run so deep that it's impossible to interpret the root cause of the mismatch just by looking at one of these 🤪

Eventually figured it out. Thread if you're curious:

Eventually figured it out. Thread if you're curious:

https://warpcast.com/darrylyeo/0x01dbdbaa

Full stack web3 development. Start building: https://thirdweb.com

Join the conversation https://warpcast.com/~/channel/thirdweb

Neovim enjoyer, "a gift to the culture" | Building at /thirdweb

The biggest thing for me is that no matter how many `Param extends X ? A : B` conditionals there are under the hood, there should always be a weaker “umbrella type” that subsumes all possible type params (including any used in nested fields) without REQUIRING me to manually cast values with `as` or redefine and forward the type params myself.

Not trivial when there are interdependent type params across functions, I realize. But a loose umbrella type would provide an escape hatch where I can choose to make strict typing opt-in.

I don’t always have time to go down rabbit holes in my library’s source code to chase down what stuff between `<` and `>` I need to copy/paste to my helper function and in what order. 😅

Yep this is a huge problem with web3 libraries in general that we’ve been thinking about @thirdweb. Would you rather have more flexible, basic types that you can build on top of to increase strictness?