-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
ts: add getAccountInfo helper method to account namespace/client #1084
ts: add getAccountInfo helper method to account namespace/client #1084
Conversation
ts/src/program/namespace/account.ts
Outdated
@@ -345,6 +343,13 @@ export class AccountClient< | |||
): Promise<PublicKey> { | |||
return await pubkeyUtil.associated(this._programId, ...args); | |||
} | |||
|
|||
async getAccountInfo(address: Address, commitment?: Commitment) { |
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 this async
can be removed?
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.
Interesting, connection.getAccountInfo
return Promise
, but no await
inside the function.
Q: function return promise or result? 🙂
A: promise will be resolved with async
or without async
. But for clarity better leave async
with await
.
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 you dont need async if you just return sth and theres no await inside the function. if it returns a promise the caller can await. I get the clarity argument but wouldnt it be more idiomatic to have an explicit return type then instead of inference and async
which implies there is an await.
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.
cool happy to amend that, wasn't sure what the convention was for this repo.
Would it make sense to add an eslint rule to enforce it in the future if that's the case?
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.
my answer was a question. not sure what the convention is myself. dont think we have one except "make prettier happy" for now. but I think that can be a discussion for a different issue
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'd prefer to have async getAccountInfo
with inner await
.
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.
If it helps, there are subtle differences to return Vs return await besides just syntactic ones.
https://eslint.org/docs/rules/no-return-await
p.s. this just has a good description of the subtle differences, not saying I support this particular rule.
https://jakearchibald.com/2017/await-vs-return-vs-return-await/
Don't mind either way, but something to take into consideration perhaps? I think another difference is that the V8 engine provides better stack traces with return await
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 another difference is that the V8 engine provides better stack traces with return await
so it would seem!
goldbergyoni/nodebestpractices#737
let's do return await
then
ts/src/program/namespace/account.ts
Outdated
const accountInfo = await this._provider.connection.getAccountInfo( | ||
translateAddress(address) | ||
); | ||
const accountInfo = await this.getAccountInfo(translateAddress(address)); |
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.
your getAccountInfo
translates the address inside so no need to do it here
@@ -9,6 +9,7 @@ import { | |||
TransactionInstruction, | |||
Commitment, | |||
GetProgramAccountsFilter, | |||
AccountInfo, |
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.
please add a line about the feature to the changelog as well
f32ca82
to
03fd1ab
Compare
Closes #640
This exposes
connection.getAccountInfo
to the namespace client's public API.I've written an integration test separately but wasn't sure how to symlink a locally built anchor cli to run the tests. It seems all the integration tests run against the published/installed version of anchor. Should I just do that separately when this change is merged and published?