refactor(experimental): graphql: slot-based nested queries #2643
Conversation
|
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @buffalojoec and the rest of your teammates on |
buffalojoec
force-pushed
the
05-05-refactor_experimental_graphql_group_schema_type_resolvers
branch
from
5f9f41e
to
e14dfd1
Compare
buffalojoec
force-pushed
the
05-05-refactor_experimental_graphql_slot-based_nested_queries
branch
from
2fe1d96
to
d400e65
Compare
| @@ -55,7 +61,9 @@ describe('account loader', () => { | |||
| const source = /* GraphQL */ ` | |||
| query testQuery($signature: Signature!) { | |||
| transaction(signature: $signature) { | |||
| slot | |||
| slot { | |||
There was a problem hiding this comment.
Doesn't this need to be renamed to block then, to reflect the new return type?
| if (onlyFieldsRequested(['slot'], info)) { | ||
| return { slot }; | ||
| } |
There was a problem hiding this comment.
How does this behave if I do:
{
block: {
__id
__type
slot
}
}Relay, for instance, basically adds __id and __type to every subselection automatically.
There was a problem hiding this comment.
Yeah GraphQL-JS adds those!
There was a problem hiding this comment.
What I mean to ask is if this resolver will get deopted (ie. make the fetch) if the client asks for __id and __type.
There was a problem hiding this comment.
Ohhh yeah it might actually. I'll add a PR for this. Good call.
| deactivationSlot: Block | ||
| lastExtendedSlot: Block |
There was a problem hiding this comment.
Still think these should be renamed to reflect the new return type.
There was a problem hiding this comment.
I truly waffled on this a bit actually. I just wanted to be careful about straying too far from the defined data, such as an account whose fields are "something-slot" and now they have to call it "block".
I couldn't decide if this was acceptable, really.
There was a problem hiding this comment.
If we leave it this way, it's going to lead to a lot of aggravating code like:
if (data.slot.slot < 123n) {
// ...
}
I'm interested to know your thoughts on whether or not we should drink from this cup some more. |
As the linked issue describes, the GraphQL resolver sports full support for
nested
Accountqueries wherever a field has typeAddress. Instead ofdefining that field to simply be of type
Address, it's defined with typeAccount,which enables nested account queries on that field based on the address
returned.
In this PR, we're taking every field with type
Slotand replacing it withBlock,to enable nested block queries in the same fashion.
Closes #1822.