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

ts: add getAccountInfo helper method to account namespace/client #1084

Merged

Conversation

dominictwlee
Copy link
Contributor

@dominictwlee dominictwlee commented Nov 30, 2021

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?

@@ -345,6 +343,13 @@ export class AccountClient<
): Promise<PublicKey> {
return await pubkeyUtil.associated(this._programId, ...args);
}

async getAccountInfo(address: Address, commitment?: Commitment) {
Copy link
Contributor

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?

Copy link
Contributor

@fanatid fanatid Dec 1, 2021

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor Author

@dominictwlee dominictwlee Dec 3, 2021

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

Copy link
Contributor

@paul-schaaf paul-schaaf Dec 6, 2021

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

const accountInfo = await this._provider.connection.getAccountInfo(
translateAddress(address)
);
const accountInfo = await this.getAccountInfo(translateAddress(address));
Copy link
Contributor

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,
Copy link
Contributor

@paul-schaaf paul-schaaf Dec 6, 2021

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

@dominictwlee dominictwlee changed the title add getAccountInfo helper to client ts: add getAccountInfo helper to client Dec 7, 2021
@dominictwlee dominictwlee changed the title ts: add getAccountInfo helper to client ts: add getAccountInfo helper method to account namespace/client Dec 7, 2021
@paul-schaaf paul-schaaf merged commit bef1bd8 into coral-xyz:master Dec 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ts: Add accountInfo to account namespace/client
3 participants