Emit redux action if fallback web3 provider is used
Closed this issue · 8 comments
It would be cool, if a redux action is emitted once the fallback web3 provider is used (at https://github.com/trufflesuite/drizzle/blob/master/src/web3/web3Saga.js#L46). The web3 redux store could then also be extended with an fellback key set to true:
{
initialized: true,
fellback: true
}
This would allow dApps to restrict certain functions to metamask users but provide also non-metamask users with some basic functions. For instance a dApp could thereby allow non-metamask users to browse content (call data with the fallback web3 provider), but restrict transaction-related functions to metamask users only.
If this behaviour is in line with your roadmap/strategy, I could submit a PR for it. Just let me know.
Thanks for this use case @mi-kas, it's a neat feature! I will discuss it with our team. Are you developing a Dapp that needs this?
@cds-amal yes, I am currently working on a dApp that would need that feature, but saw this feature also on another react-web3 binding as well
Thanks @mi-kas. I'd love to learn more about your project if possible. Also, adding my thoughts to this so I don't forget.
It's good to provide the app layer more information about the web3 connection. Right now we're addressing the use case that depend on one web3 connection path (fallback provider), but are there other use cases from the other paths? For example would a Dapp behave differently if it connected through an injected provider? I'm not sure, but these decisions should be deferred to the Dapp layer. What if we added a payload to the WEB3_INITIALIZED action item, and change the web3 state node to be an object that describes 1) status is initialized, and 2) connectionDetails is ....whatever.
Thats a good idea and would work out as well, @cds-amal. What would then be stored in the connectionDetails?
Hi @mi-kas, I'm still researching this issue. My initial thought is to set the payload to 'Fallback' | 'MM' | 'Injected'. Though It would be nice if providers consistently exposed an interface to get author/org and version so choices can be made based on provider details instead of code-path in selecting the provider. What are your thoughts?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.