timolegros
commented
3 months ago Per the protocol office hours (4/4/2024), we would like to use Wagmi on the client side and Web3JS on the platform side. Timelines for transitioning have not been set but we don't expect to act on this decision for at least another month.
Reasoning:
- Wagmi's integration with React would simplify and improve our user flows (e.g. sign-in).
- Web3JS is lighter than EthersJS
/Viemin terms of coupling with types. Since on the platform side, we interact with a lot of different contracts, it doesn't make much sense to use a package that is tightly integrated with types (requires additional type generation/parsing). While EtherJS can be used without types as well that is generally where it shines (e-to-e types). That said, we need to upgrade Web3JS to v4 before proceeding.
Edit:
- Viem should not have been part of the 'types' reasoning above. We ultimately chose not to move forward with Viem because it would be a much larger lift in our codebase than moving to Web3 or EtherJS (since we have implementations in both already).
jxom
tmm
Description
In the codebase we use both EthersJS and Web3JS. Both of these packages have essentially the same capabilities but both have their pros and cons. We should make a decision on which package we want to use and then use that accross the entire repo so we have a set standard (we can also consider Viem/Wagmi in the long-run).
If there are significant advantages to use one package over the other on the client we could consider using a different package on the client vs the server (e.g. lightweight web3 on client vs full EthersJS type-safety on the server). The main idea so to at least have a pattern of use so we don't use the same functionality from 2 different pacakges in adjacent files e.g.
checkSumfrom Web3JS andcheckSumfrom EthersJS.If we settle on using Web3JS, we need to upgrade this package to v4. v1 is now considered legacy.
The estimated points for the ticket depends on which package we choose.