-
Notifications
You must be signed in to change notification settings - Fork 788
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
refactor(experimental): graphql: slot-based nested queries #2643
refactor(experimental): graphql: slot-based nested queries #2643
Conversation
|
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @buffalojoec and the rest of your teammates on Graphite |
5f9f41e
to
e14dfd1
Compare
2fe1d96
to
d400e65
Compare
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 if we're going to drink deep from this cup, we should probably rename everything to reflect the return type.
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this need to be renamed to block
then, to reflect the new return type?
deactivationSlot: Block | ||
lastExtendedSlot: 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.
Still think these should be renamed to reflect the new return type.
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 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
e14dfd1
to
7b2bf6c
Compare
d400e65
to
d524067
Compare
7b2bf6c
to
a3956cb
Compare
I hate this PR. I think if people want this feature we can add it later, but it's kind of a beast. |
As the linked issue describes, the GraphQL resolver sports full support for
nested
Account
queries 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
Slot
and replacing it withBlock
,to enable nested block queries in the same fashion.
Closes #1822.