-
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
feat!: implement pagination for Account
methods
#2408
base: master
Are you sure you want to change the base?
Conversation
✨ A PR has been created under the |
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, but I am skeptical of the tests that just assert an object is defined, I understand it's necessary to have tests for our docs, and perhaps this pattern will be removed once #2399 lands
}; | ||
// #endregion pagination-2 | ||
|
||
expect(paginationArgs).toBeDefined(); |
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 see this pattern throughout the pagination test suite but I'm not sure what the benefit of these assertions are, given that an initialized object will always be defined.
In the context of them being passed to provider.getCoins()
I think an assertion that the pageInfo
returned is the logical consequence of a particular paginationArgs
suffices, but otherwise just asserting that a GqlPageInfo
object or CursorPaginationArgs
is defined doesn't offer any value imo.
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.
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 understand that, I elaborated a more in my final review comment , but I am suggesting that these snippet regions be incorporated into a larger test such as the ones you linked, rather than having an individual test just for the initialization of an object.
// get all coins | ||
const coins = await wallet.getCoins(); | ||
// fetches up to 100 coins from all assets | ||
await provider.getCoins(wallet.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.
Given coins
and pageInfo
are being initialized in line23, how are these results being tested?
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.
// #endregion get-spendable-resources-1 | ||
|
||
// #region get-spendable-resources-2 | ||
await wallet.getResourcesToSpend(spendableResources, excludedIds); |
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.
Should we perform an assertion on the value returned here?
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.
|
||
## Default Behavior | ||
|
||
If neither `assetId` nor `paginationArgs` are provided, the `getCoins` method will default to the base asset ID and return the first 100 items: |
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.
Where did this 100
come from?
Do we protect against huge numbers? (i.e. a user passes 1000000000
)
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.
cc @xgreenx
Coverage Report:
Changed Files:
|
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.
Another small detail about the PR description, can we also have before/after code snippets for the breaking changes? It can be helpful to let people know what needs to be updated without having to dig into the code.
"nonce": "0x03d7ad03b6a14262fc7efc59a9b95afb43af702f4becdaba866364b438b0ebd3", | ||
"amount": 18446744073709551615, | ||
"data": "", | ||
"da_height": 0 |
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 these message additions still mimicking the ones from fuel-core
?
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 you added these in for testing purposes. If that's the case, could you rewrite your tests to use launchTestNode
and the TestMessage
utility (example)?
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.
Couple comment 🥇
/** | ||
* The query parameters for this method were designed to support pagination, | ||
* but the current Fuel-Core implementation does not support pagination yet. | ||
*/ |
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 would assume that fuel-core
will implement support for pagination in the future?
With that in mind, we could keep the CursorPaginationArgs
and return a constants pageInfo
object. This could reduce the breaking changes down the line.
@@ -1392,7 +1411,7 @@ Supported fuel-core version: ${supportedVersion}.` | |||
* @param params - The parameters to query blocks. | |||
* @returns A promise that resolves to the blocks. | |||
*/ | |||
async getBlocks(params: GqlGetBlocksQueryVariables): Promise<Block[]> { | |||
async getBlocks(params: CursorPaginationArgs): Promise<Block[]> { |
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.
Do we want to return the PageInfo
from this method?
@@ -0,0 +1,65 @@ | |||
# Pagination | |||
|
|||
Pagination is highly efficient when dealing with large sets of data. Because of this some methods from the `Provider` class support GraphQL cursor pagination, allowing you to efficiently navigate through data chunks. |
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.
Pagination is highly efficient when dealing with large sets of data. Because of this some methods from the `Provider` class support GraphQL cursor pagination, allowing you to efficiently navigate through data chunks. | |
Pagination is highly efficient when dealing with large sets of data. Because of this, some methods from the `Provider` class support [GraphQL cursor pagination](https://graphql.org/learn/pagination/), allowing you to efficiently navigate through data chunks. |
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.
May be worth linking to the pagination section from GraphQL :)
Or potentially could go in a "Learn more" section?
@@ -0,0 +1,65 @@ | |||
# Pagination |
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.
May be worth adding an example of iterating over a paginated resource?
|
||
expect(message).toBeDefined(); | ||
expect(message?.nonce).toEqual(nonce); | ||
// #endregion getMessageByNonce | ||
// #endregion get-message-by-nonce-1 |
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.
Unable to suggest, however, will suggest removing the expects from the snippet :)
Breaking Changes:
The return of the following methods was modified to support pagination:
getCoins
in Provider and Account.getBalances
in Provider and Account.getMessages
in Provider and Account.