Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rifeljm/#622 walletconnect bypass readonly commands #2055

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

rifeljm
Copy link
Contributor

@rifeljm rifeljm commented Aug 31, 2023

No description provided.

@rifeljm rifeljm requested a review from paninaro August 31, 2023 16:08
@rifeljm rifeljm force-pushed the rifeljm/#622-walletconnect-bypass-readonly-commands branch from d9f0824 to 7e8243e Compare August 31, 2023 16:44
Comment on lines 234 to 236
<Typography variant="body2">
<Trans>Bypass confirmation for all read-only commands</Trans>
</Typography>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tweak wording and add an informative tooltip on hover.

⚠️ NOTE: TooltipIcon needs to be imported from @chia-network/core ⚠️

Suggested change
<Typography variant="body2">
<Trans>Bypass confirmation for all read-only commands</Trans>
</Typography>
<Flex flexDirection="row" alignItems="center" gap={1}>
<Typography variant="body2">
<Trans>Skip confirmation for all read-only commands</Trans>
</Typography>
<TooltipIcon>
<Trans>
By default, a prompt will be presented each time a WalletConnect command is invoked. Select this option if
you would like to skip the prompt for all read-only WalletConnect commands.
<p />
Commands that create a transaction or otherwise modify your wallet will still require confirmation.
</Trans>
</TooltipIcon>
</Flex>
</Flex>

@paninaro
Copy link
Contributor

paninaro commented Sep 5, 2023

  • Can we move the new "Skip Confirmation For All Readonly Commands" into the same box as "Skip Confirmation for Commands"?
  • Let's be consistent with the "readonly"/"read-only" wording. In the pairing dialog we use "read-only" but here it's "readonly". Let's go with "read-only".
  • If "Always Skip" is selected, we should hide the commands that are listed under the "Skip Confirmation for Commands" section.

image

@paninaro
Copy link
Contributor

paninaro commented Sep 5, 2023

The new bypass-readonly-commands localStorage item needs to be cleaned up properly when Disconnect, Restore, or Reset buttons are pressed:

⚠️ NOTE: The Disconnect and Restore buttons should only remove the selected dapp's topic from bypass-readonly-commands. The Reset button should completely delete the localStorage item. ⚠️

image

@@ -45,6 +46,9 @@ export default function SettingsIntegration() {
useWalletConnectPairs();

const pairs = get();
const { data: fingerprint } = useGetLoggedInFingerprintQuery();

const [bypassReadonlyCommands, setBypassReadonlyCommands] = useLocalStorage<any>('bypass-readonly-commands', {});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason not to use the useWalletConnectPairs or useWalletConnectPreferences hooks? Creating a new localStorage item is going to make maintenance more complex. At the very least we should make the naming of these localStorage items consistent -- maybe walletConnectBypassReadonlyCommands. But I would prefer using the existing hooks if possible.

@@ -334,6 +341,31 @@ export default function SettingsIntegration() {
</Box>
)}
</Flex>
<Box {...borderStyle}>
<Typography variant="h6">
<Trans>Skip Confirmation For All Readonly Commands</Trans>
Copy link
Contributor

@paninaro paninaro Sep 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Read-only" for consistency

}}
>
<MenuItem value>
<Trans>Always Skip</Trans>
Copy link
Contributor

@paninaro paninaro Sep 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about using "Always Allow" instead of "Always Skip"?

Suggested change
<Trans>Always Skip</Trans>
<Trans>Always Allow</Trans>

Comment on lines 124 to 128
let skipReadOnlyObject = {};
selectedFingerprints.forEach((f: number) => {
skipReadOnlyObject = { ...skipReadOnlyObject, [f]: true };
});
setBypassReadonlyCommands({ ...bypassReadonlyCommands, [topic.toString()]: skipReadOnlyObject });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems odd to create a nested data structure to hold a boolean. The data structure could be simplified to:

{
  <topic_1>: [fingerprint_1, fingerprint_2],
  <topic_2>: [fingerprint_3]
}

If the fingerprint is in the list, bypass confirmation is enabled. If it's not, then confirmation is required.

bypassConfirm,
onChange: handleChangeParam,
});
const isReadOnlyEnabled = bypassReadonlyCommands?.[pairedTopic]?.[fingerprint];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we rename this to something like skipConfirmation?

Copy link
Contributor

@paninaro paninaro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some edge cases and UX refinement to be ironed-out.

@paninaro
Copy link
Contributor

paninaro commented Sep 8, 2023

I'm seeing issues with the latest changes. Setting the checkbox to bypass readonly commands during pairing doesn't seem to take effect -- the walletConnectPreferences localStorage item isn't updated.

Copy link
Contributor

'This PR has been flagged as stale due to no activity for over 60
days. It will not be automatically closed, but it has been given
a stale-pr label and should be manually reviewed.'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants