apps
apps copied to clipboard
polkadot-js
Connect button for multiple wallet extensions
Currently if user has multiple dotsama wallet extensions installed, there will be multiple popups appearing at the same time
asking for permission to grant access to polkadot.js/apps. Meaning the dapp connects to all available extensions at the same time automatically without user's action.
A suggestion to add a "connect" button, that will show a popup with supported wallets and possibility to not only connect, but to download as well if user doesn't have one.
Here is an example of such button:
https://connect.subwallet.app/#/welcome
Do we want such functionality and if yes, then should this be a separate reusable library complete with UI or we just use the basics of @subwallet/wallet-connect, and create our own component for the UI part.
Currently there are multiple variants already made, there is one by @rossbulat in https://paritytech.github.io/polkadot-staking-dashboard/#/overview @talisman-connect/wallets is used there, we can use this instead of subwallet. There is one by RMRK team https://github.com/rmrk-team/substra-hooks/tree/master/packages/dotsama-wallet-react it requires some additional libs though.
None of the apps UI components are re-usable. Generally though you want something that is app specific, i.e. so it actually looks & feels like something in your specific app.
... Well, at least that is the approach taken here specifically, a community-version of this interaction, if needed here, won't be used, it will be baked into the apps UI itself.
@jacogr can @SaltyCucumber work on building a custom solution for Polkadot JS Apps?
Do you have any strong opinions on what you'd want to see? (if different than the screenshot above)
No objections. I just don't want us to get into a position of managing links/etc for multiple other wallets - they should add their own info, see known definitions & logos for those
(I have possibly been lax pointing teams to this, I have been doing so in the old days when Enzyme/SpeckleOS were the only 2 kids-on-the-block-with-grants - sadly, I have no idea which extensions are out there, I've only been made aware of one recently that did some "funny stuff" with the code, removing all attributions, but that has since been resolved)
From a usability POV, would prefer not having popups triggering other popups, if we want to fine-tune, this should be done in Settings.
Taking into account what was discussed here, this is what I'm planning to do (subject to change if something unexpected pops up in the process):
- use extensions/index.ts as the source of truth on what we support, from this source the list will be formed, this will allow others to add extensions in future, for now I'll add the polkadot extension + talisman.
- ditch all the libs, instead just use our own implementation, from what I've seen most solutions are custom made anyway, only minor methods are taken from libs
- create a dropdown when connect is clicked (good for web and mobile), less space taken, not a "popup that will trigger another popup", something that Jaco mentioned doesn't want to be happening, hence the dropdown will fit here like a glove.
@jacogr I was looking for a method to just check if dapp is authorized in extension, but can't seem to find one.
the pub(authorize.tab) triggered by .enable immediately calls for a popup which is what I don't want to happen,
so do you know a method to get a simple true/false response to a "is this dapp authorized" question or a new pub(authorize.isAuthorized) should be created for this functionality?
That would be route A.
Route B is we leave everything as is and on polkadot-js/apps I turn off automatic connection to all available extensions and instead go through a list of supported extensions and check localstorage for previously enabled extensions (list of names) if any are found - automatically connect to them. This approach will prevent multiple popups + support automatic connection to previously used extensions + require user's action to connect to "new" extensions (connect button with a dropdown list). The only down side versus route A would be that if user manually removes authorization for the dapp from all extensions, then multi-popups will appear in this case. Route A would be able to prevent this, but probably requires more changes across many packages.
What do you think?
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.
