DRAFT: Optional chaining for selection syntax #7637
Conversation
|
@andrewmcgivery, please consider creating a changeset entry in |
✅ Docs preview readyThe preview is ready to be viewed. View the preview File Changes 0 new, 19 changed, 0 removedBuild ID: 374c9a6cde711139889816dd URL: https://www.apollographql.com/docs/deploy-preview/374c9a6cde711139889816dd |
| source_id, | ||
| ); | ||
| // Make result nullable since optional chaining can produce null | ||
| Shape::one([result_shape, Shape::none()], vec![]) |
There was a problem hiding this comment.
Difference between this approach versus:
if input_shape.is_null() {
// TODO Somehow copy names from input_shape to this new
// Shape::none() shape?
(Shape::none(), None)
} else {
// TODO This should return input_shape.question() once we
// support that new child shape method.
// (input_shape.question(), Some(tail))
(input_shape, Some(tail))
}
| PathList::Question(continuation) => { | ||
| // Universal null check for any operation after ? | ||
| if data.is_null() { | ||
| (Some(JSON::Null), vec![]) |
There was a problem hiding this comment.
Should this actually be None?
| @@ -553,6 +553,10 @@ pub(super) enum PathList { | |||
| // middle/tail (not the beginning) of a PathSelection. | |||
| Method(WithRange<String>, Option<MethodArgs>, WithRange<PathList>), | |||
|
|
|||
| // Universal null guard that can wrap any path continuation. | |||
| // If data is null, returns null instead of continuing with the wrapped operation. | |||
| Question(WithRange<PathList>), | |||
There was a problem hiding this comment.
Ben's prototype had another param where The firstAdd commentMore actions parameter wraps the range of the ? token. but I am unclear as to why.
It's probably related to why Ben's version below also had depth + 1.
There was a problem hiding this comment.
But also looking at his code it seems like the first param is never actually used. 🤔
|
EDIT: This has been resolved after discussion with Ben. :) In |
Ignore for now... this is an exploration. :)
Checklist
Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.
Exceptions
Note any exceptions here
Notes
Footnotes
It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
A lot of (if not most) features benefit from built-in observability and
debug-level logs. Please read this guidance on metrics best-practices. ↩Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩