feat: tree-shakeable client types #314
Conversation
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Size Change: +4 B (0%) Total Size: 56.5 kB
ℹ️ View Unchanged
|
tmm
force-pushed
the
tmm/tree-shakeable-client-types
branch
from
4d8935a to
0dff606
Compare
Codecov Report
@@ Coverage Diff @@
## main #314 +/- ##
=======================================
Coverage 99.88% 99.88%
=======================================
Files 262 262
Lines 16808 16812 +4
Branches 1795 1795
=======================================
+ Hits 16788 16792 +4
Misses 18 18
Partials 2 2
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
|
What does tree-shakable types even mean? Aren't all types tree shaken essentially both in .js and .d.ts files? |
Yeah, the types aren't tree-shakeable. This PR allows you to create a plain const client = createClient({ transport: http() })
const res = await readContract(client, {
abi: seaportAbi,
address: '0x',
functionName: 'name',
})Right now, only "decorated" clients can be used with actions. By allowing folks to also use |
|
oh sick! Yea I remember when I first looked at viem this action(client, ...params) api was all I saw and I don't think decorated clients existed. Was very surprised later when you went the route of slightly more ergonomic ux for some % of devs with client.action syntax over the hyper optimized code splitting based on how ya'll seemed to be thinking about viem |
|
I don't think I represent the majority, but will mention I hate this. Two different ways to do the same thing. If we had the tree shakable version that takes the object as it's first argument, adding dot syntax just to appease the autocompleters feels like a bad reason to add a second way of doing things. Similarly here it feels like a bit of an over-optimization (especially considering how hard viem is already crushing competition here) to include this as a tree shaking optimization What would make me not hate it would be if this was a seperate library maybe called @viem/core or @viem/internal and viem simply just consumed that library and added decorators maybe some other nice to haves. I would like that you pick 1 way of doing things when you install but still would find the two library options unnecessary for this. Like I said I don't think I represent the majority opinion though How big is the codesplitting win here btw if it's huge that would change my mind (though it would make me wish the dot syntax didn't exist) |
|
Closing since this is stale. Will open in follow-up. |
Allows
Clienttype to be used with public and wallet actions for maximum tree shakeability.Doesn't work with test actions right now since they have a more complex type set up (e.g.
mode).🤖 Generated by Copilot at 0dff606
Summary
🧪🔄🤝
This pull request enhances the compatibility and flexibility of the actions module by refactoring the functions to accept different types of clients from the
clientsmodule. It also adds tests for the actions module using thevitestframework. It affects the files in thesrc/actionsdirectory and the new filesrc/actions/actions.test-d.ts.Walkthrough
vitestframework in a new fileactions.test-d.ts(link)Clienttypes instead of onlyPublicClientorWalletClienttypes, to make the actions more flexible and compatible with different types of clients (link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link)getContractfunction and theGetContractParameterstype to match the order of theClienttype, which isTChain,TAccount,TTransport, for consistency and ease of use (link, link, link)createPendingTransactionFilterfunction to match the order of theClienttype, which isTChain,TTransport, for consistency and ease of use (link)trimimport from theutilsmodule in thegetEnsAddressfile to follow the code style and formatting rules (link)