-
Notifications
You must be signed in to change notification settings - Fork 10
refactor: rename fetch to get, object arguments for >2 args methods #93
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
Conversation
…getExecutionReceipts
with >2 arguments, specially if some have same type, it's more descriptive and unambiguous to have them fully specified by name be callers in an object argument, instead of positional arguments
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Coverage Report |
| router, | ||
| destChainSelector, | ||
| message, | ||
| }: Parameters<Chain['getFee']>[0]): Promise<bigint> { |
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.
Why don't you directly reference SendMessageOpts?
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.
As I had mentioned in message, I want the SoT to be the actual method declarations; in this case, for example, getFee could chose to omit some property from the required type (which is kinda common between getFee, generateUnsignedSendMessage and sendMessage), so referencing the actual method allows that to always stay in sync. The explicit type is used only for docs purpose
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.
You can even see this now, where getFee omits approveMax, which is common to generateUnsignedSendMessage and sendMessage
| /** | ||
| * Common options for [[generateUnsignedSendMessage]] and [[sendMessage]] Chain methods | ||
| */ | ||
| export type SendMessageOpts = { |
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.
Are we reexporting SendMessageOpts and ExecuteReportOpts from index?
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.
Nope, because I said, I don't want them to be used/referred directly, and instead the actual declarations to be the reference point
| commit?: CCIPCommit, | ||
| hints?: Pick<LogFilter, 'page' | 'watch'>, | ||
| ): AsyncIterableIterator<CCIPExecution> { | ||
| async *getExecutionReceipts({ |
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.
why we don't use name types for consistency with the other methods?
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.
Because I don't want those named types to be used, much less these with a single use: I don't want to pollute namespace with type(aliases) which are used only once.
Those 2 which I named (SendMessageOpts, ExecuteReportOpts), are only because they're used (locally) multiple times.
7039eed to
50ff549
Compare
for consistency with other method names
4295bb4 to
c6c6e75
Compare
fetch*toget*methods