Closed leonprou closed 4 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.
@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:
setFirstValidConnectors
will have an option to pass an array of arrays or object of arrays. For example for my example to have 2 connections simultaneously I could do: context.setFirstValidConnector({ ethereum: ['MetaMask', 'InfuraEthereum'], sidechain: ['MetaMask', 'SidechainRpcProvider']})
. This setting will mean that web3-react
will try to use Metamask and if it fails to use the rpc (Metamask connector should also check that the networkId
is correct)getContext
will retrieve the current context object - https://github.com/NoahZinsmeister/web3-react#context. like `getContext('ethereum').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.
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.
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
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
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?