Content
@
https://warpcast.com/~/channel/fc-devs
0 reply
0 recast
0 reaction
Darryl Yeo đ ïž
@darrylyeo
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 đ€Ș
4 replies
0 recast
31 reactions
Darryl Yeo đ ïž
@darrylyeo
@v, you wanted more context on the `@ts-ignore`⊠This was the context đ
1 reply
0 recast
1 reaction
Darryl Yeo đ ïž
@darrylyeo
Anyway, after several hours I eventually figured out the right type parameters to add in order to satisfy the system đźâđš
1 reply
0 recast
3 reactions
Darryl Yeo đ ïž
@darrylyeo
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`):
2 replies
0 recast
2 reactions
Fucory
@fucory
Yea this is good insight. I personally avoid ALL defaults internally and only use defaults if 1. Itâs copy pasta code 2. Itâs public code and the default is for end user convenience
1 reply
0 recast
0 reaction
Darryl Yeo đ ïž
@darrylyeo
Yeah, it's sometimes unavoidable as an app dev because at mininum you have to replicate the defaults that came with the library to avoid potential clashes.
1 reply
0 recast
1 reaction
Fucory
@fucory
Interesting thing about working with wrapping libraries that have defaults is you actually could just use `any` as the default 100% of the time without losing any typesafety e.g. WalletClient<any, any, any, any, any> is the the same thing as hand crafting every default to match viem
1 reply
0 recast
0 reaction
