Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migration to wagmi v1 and viem #352

Merged
merged 79 commits into from
Jul 5, 2023
Merged

Migration to wagmi v1 and viem #352

merged 79 commits into from
Jul 5, 2023

Conversation

technophile-04
Copy link
Collaborator

@technophile-04 technophile-04 commented May 24, 2023

Plan of action :

  • Migrate all the easy files ( File not using ethers / not deeply dependent on wagmi )

  • Migrate main file ( Deeply dependent on ethers and wagmi )

  • Lastly remove ethers as dependencies from nextjs workspace

    • Some places like @uniswap/sdk still rely on ethers provider

Bugs Iteration :

Work In progress :

Notes :

The viem migration guide and wagmi migration guide are pretty robust and nice

But here is the main difference between ethers and viem :

  • In viem instead of providers / signers we have clients, so there are total 3 types of client
  • Each client can be used to call different rpc methods( viem likes to call them actions )
  • Example Public client can be used to call Public actions ( rpc calls ) like eth_blockNumber etc
  • Example Wallet client can be used to call Wallet actions ( rpc calls ) like eth_sendTransaction etc (There is no concept of Signer instead it calls the Accounts)

Additional Information

Related Issues

Fixes #229

Your ENS/address: shivbhonde.eth , solidixen.eth

@sverps
Copy link
Collaborator

sverps commented Jun 2, 2023

I started with updating useScaffoldContractWrite. A question: I recall a discussion about the recklesslyUnprepared mode and not using usePrepareContractWrite, does anyone remember what was up with that?

@technophile-04
Copy link
Collaborator Author

I recall a discussion about the recklesslyUnprepared mode and not using usePrepareContractWrite, does anyone remember what was up with that?

#215 has the reason why it was removed, but were planning to add it again in #269 due to #216 (comment)


But in wagmi v1 its not mandatory also :
Screenshot 2023-06-03 at 5 45 05 AM

Also, they removed have removed the problem mentioned in #216 (comment) from https://wagmi.sh/react/prepare-hooks page

So I think we won't be needing #269 since the issue can be resolved without using Prepare Hooks in v1 🙌

@technophile-04
Copy link
Collaborator Author

Update :

  1. update parsing of error and small formatting tweak at fcb9703 :
Before V1 After
  1. Got back the similar behaviour to main when values are too big they are shown as Ξ 2.1 etc cf63271

  2. There was a bug when you send small value like 1 wei its was used to send 49 wei fixed at d76328c

  3. Also fixed some todos

BUG's Noticed :

  1. bug: autoConnect is not working  #391

  2. Handling passing of array / structs of inputs :

We have this logic in main

      if (["array", "tuple"].includes(baseTypeOfArg)) 

But it seems now viem / wagmi does like to parse it as :
Screenshot 2023-06-30 at 12 25 26 AM

We can maybe check if there includes [ then its an array 🤔 need to think about it, will have a look at it tomorrow

Here is the example contract to test it out -> 1f22545 (look at previous changes)

@technophile-04
Copy link
Collaborator Author

technophile-04 commented Jun 30, 2023

@sverps could you please check for 1f46ed9 .....It tries to remove the need for assertion since it was giving errors when a contract is not present

Lol it's bit hacky but please feel free to update it 🙌

@sverps
Copy link
Collaborator

sverps commented Jun 30, 2023

@sverps could you please check for 1f46ed9 .....It tries to remove the need for assertion since it was giving errors when a contract is not present

Lol it's bit hacky but please feel free to update it 🙌

Cleaned it up a bit. I also found a very nice utility type Prettify. Will go through the types to see where we could use it to provide nicer types for devs. (Check the resulting type also after removing the Prettify<...> wrapper if you want to see what it does)

@technophile-04
Copy link
Collaborator Author

also found a very nice utility type Prettify. Will go through the types to see where we could use it to provide nicer types for devs.

Omg love this, great find !! Such a great utility always had a hard time seeing just the Abstract type name instead of the resultant type, Yes we should it update wherever possible

@technophile-04
Copy link
Collaborator Author

technophile-04 commented Jul 4, 2023

Fixed some bugs and clean up starting from 9ab3636... Also tested all the things nicely and everything seems to work as main

Marking this Ready for review since everything looks cool now 🙌

We have just 2 todo's (can be conqured async with testing) :

  1. bug: autoConnect is not working  #391
  2. Using Prettify for better types hint as mentioned in Migration to wagmi v1 and viem #352 (comment)

@technophile-04 technophile-04 marked this pull request as ready for review July 4, 2023 09:12
@carletex
Copy link
Member

carletex commented Jul 5, 2023

I'm live testing & debugging with @technophile-04 at ETH Barcelona 🤓

We notices that there was an error when inputting decimals on the tx value field (Interger Input). It was because an uncomplete decimal can't be converted to BigInit. Pushed a fix

image

@carletex
Copy link
Member

carletex commented Jul 5, 2023

We think the main stuff looks great (maybe some bugs will come up), so let's merge!!!

Really nice work @technophile-04 & @sverps

@carletex carletex merged commit 7d3e47b into main Jul 5, 2023
@carletex carletex deleted the migration/wagmi-1.x branch July 5, 2023 11:33
@technophile-04 technophile-04 mentioned this pull request Jan 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Migration from ethers to viem (and wagmi 1.*)
3 participants