-
Notifications
You must be signed in to change notification settings - Fork 2k
RFC: Client Controlled Nullability Operators Implementation #3281
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
Conversation
@twof try rebasing and overwriting author on commits https://stackoverflow.com/a/54363151/11321732 |
f44f30d
to
05f95f7
Compare
@saihaj Thanks! That worked. |
@twof I enabled CI, and some tests are failing. |
@IvanGoncharov Thanks! I'll go through these issues. |
@IvanGoncharov Mind kicking this off again? I think I've resolved the issues. I also ran the test coverage checker locally, and it looks like we ought to be good to go I think. |
Thanks! I'll fix that spelling |
src/validation/rules/RequiredStatusOnFieldMatchesDefinitionRule.ts
Outdated
Show resolved
Hide resolved
@@ -12,6 +12,7 @@ import { getNamedType, isCompositeType } from '../../type/definition'; | |||
|
|||
import { buildSchema } from '../buildASTSchema'; | |||
import { TypeInfo, visitWithTypeInfo } from '../TypeInfo'; | |||
import { ComplexRequiredStatus } from '../../language/ast'; |
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 might need a test in this file somewhere
// Errors will have already been handled by RequiredStatusOnFieldMatchesDefinitionRule | ||
// so there's no need to do anything here in the event that modifiedOutputType throws | ||
// an error. | ||
try { | ||
var modifiedType1 = modifiedOutputType(type1, node1.required); | ||
var modifiedType2 = modifiedOutputType(type2, node2.required); | ||
|
||
if (doTypesConflict(modifiedType1, modifiedType2)) { | ||
return [ | ||
[ | ||
responseName, | ||
`they return conflicting types "${inspect( | ||
modifiedType1, | ||
)}" and "${inspect(modifiedType2)}"`, | ||
], | ||
[node1], | ||
[node2], | ||
]; | ||
} | ||
} catch {} |
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.
Is it okay not handling errors here if I expect the errors these functions throw to be handled in a different rule? Is there any reason to think one rule will be run and the other won't?
* A GraphQL document is only valid if all fields selected are defined by the | ||
* parent type, or are an allowed meta field such as __typename. | ||
* | ||
* See https://spec.graphql.org/draft/#sec-Field-Selections |
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.
Update this link once I've added this rule to the spec
@IvanGoncharov I'll take a look at those failing jobs in the morning, but I'll go over everything and do some cleanup in the morning, so don't worry too much about the details for now. Also let me know if there are any portions you'd like me to write up explanations for. Summary of changes:
Todo:
|
@IvanGoncharov Hey Ivan. During the meeting last Thursday you mentioned that you'd be open to releasing this feature behind an experimental flag while it's still in review, and you had some other features that did something similar in the past. Are you able to point me towards an example of a feature that used an experimental flag? I can implement something similar as part of this PR if you're still interested in doing that. |
Hey @twof we currently publish But I think this approach really isn't working well and @IvanGoncharov wanted to merge everything to |
I assume you are on node |
@saihaj Great! Let me know if there's anything I can do to help with the experimental flag setup, or if yall have anything else I can fix up about the PR. It looks like most checks are passing. |
@twof I suggest moving in steps. That way we will merge noncontroversial stuff first and focus on stuff that needs disscussion. |
@IvanGoncharov Here's the PR with the stuff you asked for: #3418 |
Hey @michaelstaib! Thanks for the review. I'm in the process of breaking up this PR into smaller changesets. I've addressed your feedback for the @IvanGoncharov @saihaj In order to reduce confusion, would it be helpful to close this PR and designate #3418 as the canonical implementation branch for this RFC? |
Implementation of graphql/graphql-spec#867 along with the suggested
?
syntax.Here's a doc with a list of some of the important test cases and the justifications for their behavior.
This PR includes work done by @xuewei8910, @aprilrd, @magicmark, and @lizjakubowski.