-
Notifications
You must be signed in to change notification settings - Fork 7
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
[ENG-180 | ENG-182]
Unsupported ENS networks
#2709
[ENG-180 | ENG-182]
Unsupported ENS networks
#2709
Conversation
…allback to mainnet if not provided
… if not supported
…et if not supported
…net if not supported
Deploying decent-interface with
|
Latest commit: |
f884b6c
|
Status: | ✅ Deploy successful! |
Preview URL: | https://a6250261.decent-interface.pages.dev |
Branch Preview URL: | https://eng-180-182-ens-error-unsupp.decent-interface.pages.dev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall - though I'm wondering whether it's a best way to organize errors handling and whether returning null
/ empty string might be better idea
let effectiveChainId: number; | ||
if (props?.chainId !== undefined) { | ||
if (!supportedEnsNetworks.includes(props.chainId)) { | ||
throw new Error(`ENS is not supported for chain ${props.chainId}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This error throwing inside hook's body makes me little nervous - should we just return "nothing" instead? Or the idea is that components / hooks that are using useNetworkEnsAddress
are covering underlying usage with some sort of safety gates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The error thrown is to alert us. if we use this getENSName
inproper case. say we have feature thats pulling info from a third party with a chain id and a address. instead of just defaulting to mainnet silently. this will alert us a problem as it could be unintentional.
That make sense?
let effectiveChainId: number; | ||
if (args.chainId !== undefined) { | ||
if (!supportedEnsNetworks.includes(args.chainId)) { | ||
throw new Error(`ENS is not supported for chain ${args.chainId}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question here
|
||
if (props?.chainId !== undefined) { | ||
if (!supportedEnsNetworks.includes(props.chainId)) { | ||
throw new Error(`ENS is not supported for chain ${props.chainId}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here
Need this work. Merging as we have approvals |
Suspect IssuesThis pull request was deployed and Sentry observed the following issues:
Did you find this useful? React with a 👍 or 👎 |
sorry @DarksightKellar
Closes ENG-180
Closes ENG-182
@adamgall Called out about the fallback to mainnet, but I pushed back only thinking about the argument
chainId
and protecting against unintentionally setting it to call an unsupported network.Screenshots