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
Darryl Yeo đ ïž
@darrylyeo
Here's the commit in case you were curious @awkweb @jxom: https://github.com/farcasterxyz/hub-monorepo/pull/2181/commits/9fcb2a23f4172e02890f9cee91c5df72faa73e29
0 reply
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
