-
Notifications
You must be signed in to change notification settings - Fork 44
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
fix: Add __typename support #871
Conversation
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. Just a single question.
@@ -13,6 +13,11 @@ Package core provides commonly shared interfaces and building blocks. | |||
*/ | |||
package core | |||
|
|||
import ( | |||
"github.com/sourcenetwork/defradb/client" | |||
parserTypes "github.com/sourcenetwork/defradb/query/graphql/parser/types" |
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.
question: There are no conflicts here so why specify a name for the package? types
is also shorter.
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.
tradition/consistency - parserTypes
is used everywhere. I have a minor preference to leaving it as is, but do let me know if you strongly prefer the removal of the alias
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 always prefer to avoid aliases unless there is a conflict or if the package name is unwieldy regardless of tradition. But not a strong enough preference to push back if you want to keep it like that. That's why it was only a question.
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.
Will leave as is then unless someone else chimes in before the build completes
c2d0718
to
cb5f68e
Compare
As per GQL spec
cb5f68e
to
f3d5d14
Compare
Codecov Report
@@ Coverage Diff @@
## develop #871 +/- ##
===========================================
+ Coverage 59.79% 59.83% +0.04%
===========================================
Files 157 157
Lines 17425 17443 +18
===========================================
+ Hits 10419 10437 +18
Misses 6068 6068
Partials 938 938
|
As per GQL spec
Relevant issue(s)
Resolves #674
Description
Adds __typename support as per GQL spec.
I think I got all applicable types, but please try have a quick think if there is anything else that I may have missed (collections, groups, commits, commit-links).
I chose to add the prop on the render step, as the field is not targetable (via sort, filter etc) (we may wish to change that at somepoint, but as we dont support gql unions atm I saw no use case for that) and there seemed little point in duplicating the prop across all the documents until last minute.
Specify the platform(s) on which this was tested: