Skip to content
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

Closed

Conversation

kl4n4
Copy link

@kl4n4 kl4n4 commented Mar 21, 2019

Implements arguments for interfaces (#260 and #261)

allows for GraphQL schemas like the following to be defined:

interface Article {
  id: ID!
  headline: String
  image(height: Float!, width: Float!): String!
}

type WebArticle implements Article {
  id: ID!
  headline: String
  image(height: Float!, width: Float!): String!
  url: String!
}

using the following syntax:

@InterfaceType()
abstract class Article {
    @Field(type => ID)
    id: string;

    @Field({ nullable: true })
    headline?: string;

    @Field()
    image1(@Arg("width") width: number, @Arg("height") height: number): string {
        return `http://lorempixel.com/${width}/${height}/`;
    }
}

@ObjectType({ implements: Article })
class WebArticle extends Article {
    @Field()
    url: string;
}

@kl4n4 kl4n4 changed the title Feature/arguments for interface fields Arguments for fields of interfaces Mar 21, 2019
@codecov
Copy link

codecov bot commented Mar 21, 2019

Codecov Report

Merging #284 into master will increase coverage by 0.32%.
The diff coverage is 100%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
src/schema/schema-generator.ts 96.46% <100%> (+0.05%) ⬆️
src/schema/utils.ts 100% <0%> (+17.64%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cb956aa...5e3bc44. Read the comment docs.

@MichalLytek MichalLytek force-pushed the master branch 2 times, most recently from 01796f6 to be55e3c Compare March 23, 2019 18:39
@MichalLytek MichalLytek self-requested a review March 24, 2019 17:09
@MichalLytek MichalLytek added Enhancement 🆕 New feature or request Community 👨‍👧 Something initiated by a community labels Mar 24, 2019
@MichalLytek
Copy link
Owner

MichalLytek commented Mar 24, 2019

@kl4n4
Please rebase your changes, I've made some tweaks in readme and force pushed them on master.

Copy link
Owner

@MichalLytek MichalLytek left a 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 😉

tests/functional/interfaces-with-arguments.ts Outdated Show resolved Hide resolved
tests/functional/interfaces-with-arguments.ts Show resolved Hide resolved
tests/functional/interfaces-with-arguments.ts Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
@kl4n4
Copy link
Author

kl4n4 commented Mar 26, 2019

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.

@kl4n4
Copy link
Author

kl4n4 commented Mar 28, 2019

Hi @19majkel94, I now fixed all open issues, updated the changelog, added a small doc part and extended the interface example.
I hope now everything looks okay to you - if you still have any issues or suggestions, please let me know. Otherwise I hope this PR helps out one or two other users ;)

Copy link
Owner

@MichalLytek MichalLytek left a 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 😉

docs/interfaces.md Show resolved Hide resolved
docs/interfaces.md Show resolved Hide resolved
examples/interfaces-inheritance/person/person.type.ts Outdated Show resolved Hide resolved
tests/functional/interfaces-with-arguments.ts Outdated Show resolved Hide resolved
tests/functional/interfaces-with-arguments.ts Outdated Show resolved Hide resolved
tests/functional/interfaces-with-arguments.ts Outdated Show resolved Hide resolved
tests/functional/interfaces-with-arguments.ts Outdated Show resolved Hide resolved
tests/functional/interfaces-with-arguments.ts Outdated Show resolved Hide resolved
@MichalLytek
Copy link
Owner

@kl4n4
Are you going to continue working on this PR? 😉

@kl4n4
Copy link
Author

kl4n4 commented Apr 20, 2019

sry for the hiatus - my work&projects kept me busy lately but I should find the time now during the easter break.

@kl4n4
Copy link
Author

kl4n4 commented Apr 27, 2019

@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.

docs/interfaces.md Show resolved Hide resolved
return `${intValue1}-${intValue2}`;
}
@Field()
implemetingObjectTypeFieldArgumentsType(@Args() args: SampleArgs1): string {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

expect(sampleField.args).toBeDefined();
expect(sampleField.args.length).toEqual(2);
expect(
sampleField.args.every(arg => ["intValue1", "intValue2"].includes(arg.name)),
Copy link
Owner

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 })
Copy link
Owner

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.

Copy link
Owner

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(
Copy link
Owner

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 {
Copy link
Owner

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.

@chrisdostert
Copy link

is it possible to get this merged? I'm also eagerly waiting on it. Thanks @kl4n4 and @19majkel94 !

@MichalLytek
Copy link
Owner

is it possible to get this merged?

@chrisdostert
If you have some time you can help and change the requested parts of the code 💪

@chrisdostert
Copy link

@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
(https://github.com/opctl and https://github.com/opspec-pkgs to name a couple) .

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 : /

@chrisdostert
Copy link

@MichalLytek @kl4n4 any update on this?

@MichalLytek
Copy link
Owner

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 🔒

@MichalLytek MichalLytek added the Wontfix ❌ This will not be worked on label Mar 15, 2020
@MichalLytek
Copy link
Owner

MichalLytek commented Mar 23, 2020

#579 has been merged! 🎉

Thank you very much @kl4n4 for your work on this PR ❤️
It's a bit sad that you haven't find time to finish this PR and a bit shame for me that it took one year to add support for this simple feature 😞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Community 👨‍👧 Something initiated by a community Enhancement 🆕 New feature or request Wontfix ❌ This will not be worked on
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants