-
Notifications
You must be signed in to change notification settings - Fork 51
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
Feature/config #396
Feature/config #396
Conversation
5c5a8ca
to
ed8d1ba
Compare
const { | ||
params: { address, dseq }, | ||
searchParams: { network } | ||
} = DeploymentDetailPageSchema.parse(props); |
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 will throw an error if the props are not correct?
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.
yea
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.
I think network id should have a default value of mainnet.
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.
so let's imagine someone implements a link to this page on the frontend. The one may notice that it works without the network params and not bother why it's needed. Thus we may get a bug when a mainnet link is opened from, say, staging.
I'd say it should fail in 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.
I suppose yea, we do append the network param to the path everywhere is use it so it should be fine.
ed8d1ba
to
9182d12
Compare
PR commits are describing what's done. It's also a step-by-step guide to apply to provider-web