-
-
Notifications
You must be signed in to change notification settings - Fork 677
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
Arguments for fields of interfaces #284
Arguments for fields of interfaces #284
Conversation
Codecov Report
@@ Coverage Diff @@
## master #284 +/- ##
=========================================
+ Coverage 94.38% 94.7% +0.32%
=========================================
Files 69 69
Lines 979 982 +3
Branches 74 76 +2
=========================================
+ Hits 924 930 +6
+ Misses 52 49 -3
Partials 3 3
Continue to review full report at Codecov.
|
01796f6
to
be55e3c
Compare
@kl4n4 |
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.
We should also update changelog and the most important: update the docs to add info that now you can do such things with interface fields and arguments 😉
currently there is an issue with resolving fields of interfaces when using inline arguments. I will investigate and fix this ASAP but I already pushed the tests for reference. As soon as this is fixed I will update the change log and docs. |
and other missing properties
Hi @19majkel94, I now fixed all open issues, updated the changelog, added a small doc part and extended the interface 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.
Great work! 💪
There's a few issues I would like to ask you to fix 😉
@kl4n4 |
sry for the hiatus - my work&projects kept me busy lately but I should find the time now during the easter break. |
@19majkel94 unfortunately it again took me a little longer than expected to finish this. But now it should be done :) I added additional tests for the use case you described in your comments, changed the example back to the way you intended it and adapt everything I could find and think of according to your comments. please just let me know, if I missed something or there are still remaining issue with the way I implemented this feature. |
return `${intValue1}-${intValue2}`; | ||
} | ||
@Field() | ||
implemetingObjectTypeFieldArgumentsType(@Args() args: SampleArgs1): string { |
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.
expect(sampleField.args).toBeDefined(); | ||
expect(sampleField.args.length).toEqual(2); | ||
expect( | ||
sampleField.args.every(arg => ["intValue1", "intValue2"].includes(arg.name)), |
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.
Less magic, more explicitness - please use sampleField.args.find
to get two variables and normal assertion, just like in resolvers
test suite, instead of every
, includes
and toBeTruthy
.
|
||
@ArgsType() | ||
class SampleArgs1 { | ||
@Field(type => Int, { nullable: true, defaultValue: 50 }) |
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.
Remove the nullable and defaultValue noise if it's not needed or rename the args to reflect that if it's a part of a test case.
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.
Maybe inlineIntValue1
and argsIntValue1
to distinguish the inline from class args in tests.
}); | ||
|
||
it("should have proper arguments for the interface field with inline arguments", async () => { | ||
const sampleField = (schemaIntrospection.types.find( |
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.
Please use temporary variables instead of non-readable long chaining with types assertion. sampleField
can be a variable initialized in beforeAll
.
} | ||
|
||
@ObjectType({ implements: SampleInterface1 }) | ||
class SampleImplementingObject1 implements SampleInterface1 { |
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.
The ObjectType extends InterfaceType
is a nice pattern to reduce the boilerplate of redeclaring fields, we should support that too as it's handy with sharing implementation of interface field resolver. So please test that behavior in both schema and functional way and also check overriding the inline field resolvers methods from base interface.
is it possible to get this merged? I'm also eagerly waiting on it. Thanks @kl4n4 and @19majkel94 ! |
@chrisdostert |
@MichalLytek I hate this answer which is why I didn't respond right away, but I don't have the time to dig into this project to get comfortable enough to contribute : / . I also have FOSS projects outside of my day & night jobs that suck up all my extra time Going through issues, multiple have been filed asking for this functionality. Is it possible to get the PR in so people can start using the functionality, and touchups to the implementation can always be revisited? I would hate to see the amount of work @kl4n4 has gone to go to waste : / |
@MichalLytek @kl4n4 any update on this? |
Due to lack of "Allowing changes to a pull request branch created from a fork", I am forced to close this PR in favor of the revamped #579 🔒 |
Implements arguments for interfaces (#260 and #261)
allows for GraphQL schemas like the following to be defined:
using the following syntax: