Farcaster Devs

Viem

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. 😅

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 🤪

TypeScript Interface for Ethereum ~ viem.sh

@v, you wanted more context on the `@ts-ignore`…

This was the context 😂

Technowatermelon. Elder Millenial. Building Farcaster. 

nf.td/varun

/frontend dev (HTML/CSS)・founder/decentralized data wrangler /blockhead・contributor /ethglobal /walletbeat・hackathon bounty hunter・music maker・dropout・nomad・25

Anyway, after several hours I eventually figured out the right type parameters to add in order to satisfy the system 😮‍💨

I definitely have a better grasp on managing type parameters now. Basically, keep defaults as broad as possible, if not the same as the constraint.

Takes discipline, but if you do it right you won't be tempted to duplicate parameters all the way up the dependency tree (like I almost did here for `Hub` / `SyncEngine`):

Here's the commit in case you were curious @awkweb @jxom:

Here's the commit in case you were curious @awkweb @jxom:

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