Uniswap / web3-react

A simple, maximally extensible, dependency minimized framework for building modern Ethereum dApps
https://web3-react-mu.vercel.app/
GNU General Public License v3.0
5.54k stars 1.52k forks source link

Managing multiple web3 instances. #22

Closed leonprou closed 4 years ago

leonprou commented 5 years ago

Interesting project!

But in my case we have 2 web3 instances connected to different networks (Ethereum and a sidechain). Can I manage multiple connections with web3-react?

NoahZinsmeister commented 5 years ago

thanks @leonprou !

i totally hear you on this multiple instances thing, it's been a point of annoyance for me, as i haven't yet figured out a clean way to do this.

of course the hackiest way would be to simply write a custom connector which hitchhikes on top of the global context provided by web3-react and contains a bunch of methods that expose custom providers, etc.

another option would be to have some concept of a persistent connector (which talks with your sidechain, say) and a transient one (which could manage any arbitrary wallet connected to mainnet).

to generalize this, maybe it makes sense to allow multiple <Web3Provider> components in the same root or project.

an even further generalization might be a totally native multi-connector framework, though i foresee that managing this type of setup might be fairly fragile/unintuitive.

would love to hear your thoughts on this! also some useful information for me might include whether your users are using the same/different addresses across mainnet/sidechain, whether you're using network connectors or injected, etc.

leonprou commented 5 years ago

@NoahZinsmeister Hey, thanks for starting this conversation :)

Looking into the current API and my use case, I'm thinking about more general "multicontext" that can manipulate multiple connections. It will have functions such:

Also, making it that way also will require some renaming, the names of "context" and "multicontext" are not quite good.. But we can think about it latter.

What do you think? I can advice only about the API now, not the implementation.. But making such an API should work like an extension that will not make the single connector case more complicated.

NoahZinsmeister commented 4 years ago

hey @leonprou , just a quick update on this. right now i'm considering keying useWeb3React() by connector to support >=1 connectors.

under the hood it'd use connector.constructor.name to keep track of all connectors currently set (either active or in an error state), in the multi-content case. of course it'd fallback gracefully so you wouldn't even have to think about it in the single-context case.

NoahZinsmeister commented 4 years ago

for some context, connectors aren't going to be named anymore in v6 but instead passed around as objects, hence using connector.constructor.name instead of a string client-side

NoahZinsmeister commented 4 years ago

ok i solved this in a nice way! code forthcoming, but the tldr is that in v6 (with some minimal config) it'll be possible to call useWeb3React(key) to access separate contexts, meaning you'll be able to maintain two (or more) entirely distinct roots for all the mainchain/sidechain shenanigans your heart could desire