search

rainbow-me / rainbowkit

The best way to connect a wallet 🌈 🧰
https://rainbowkit.com
MIT License
2.44k stars 664 forks source link

[bug] recreating a connectors list breaks the Connection button #1265

Closed bulgakovk closed 10 months ago

bulgakovk commented 1 year ago

Is there an existing issue for this?

RainbowKit Version

1.0.0

wagmi Version

1.0.5

Current Behavior

If you recreate a connectors list, it disrupts the connection flow, requiring a page refresh to display the connected wallet address after connecting to it.

https://user-images.githubusercontent.com/8983736/236782094-eb9814e2-40e5-4a07-8363-8631c54eff20.mov

Expected Behavior

The wallet address should be visible immediately after connecting to it.

Steps To Reproduce

Please see a Github repository with a PoC below.

Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)

https://github.com/bulgakovk/connect-button-PoC

Anything else?

When I was debugging the issue, I've noticed that useConnectionStatus hook doesn't update its value there so that's why that condition will be false and the connected wallet will not be displayed immediately.

I've tried to distillate the Wagmi only part to a separate branch: https://github.com/bulgakovk/connect-button-PoC/tree/bulgakovk/feat/drop-rainbowkit-dependency (since useConnectionStatus depends on useAccount hook from Wagmi). But the Wagmi hook seems to be working fine on that line.

A rationale for updating the connectors list could be found there: Wallet Standard connector request. Essentially, Standard Wallets possess an asynchronous registration (injection) API, which allows for the wallets list to be updated dynamically, and as a result, the connectors should be updated.

DanielSinclair commented 1 year ago

@bulgakovk Thanks for the detailed report here. This leans towards expected behavior currently as this is an atypical use of Wagmi, and the connector architecture has historically been designed to prepare connectors only once on page load. But I'll leave this open to see if it is possible to resolve this side effect without diverging from that architecture design. I'm not quite convinced that recreating the connector list is the correct end-goal or a viable approach for Wallet Standard connectors. We would instead need a deeper refactor where a single connector communicates with all Wallet Standard-supporting providers, and the 1-to-1 coupling of connectors to wallets would need to be deprecated. The standards are still waiting to be settled between EIP-5749/EIP-6963 and Wallet Standard, so we likely won't move forward here for a little while.

magiziz commented 10 months ago

@bulgakovk Are you still seeing this issue on your end ? If not we can close this issue.