Abstract filter argument

[benjie]

@magicmark: please fully replace this description with your own.

---

Read the README as the first thing, the spec is just super rough key algorithms and rules.

This PR is a quick (hah!) write up of my thoughts following a chat with @magicmark this morning. I've opened it as a draft with the intent of @magicmark editing it as he sees fit (or replacing it!) and the completing a first draft. It is far from complete, with major gaps, but I hope it helps to capture some of the points discussed and the reasoning behind some of the decisions we're leaning towards.

Please note that the draft spec is NOT fully in spec-like language; such work (especially around talking about connections, and the specifics of returning [AbstractType] vs [AbstractType!]!) would take a lot longer so I've mostly skipped over it.

@magicmark You may merge this as-is and the follow up with your own edits, or edit it directly in this PR, I don't mind. We're pretty flexible on what gets merged into the RFCs folder. Also the names of things are all placeholders, feel free to replace! Ideally keep the git history intact though :)

[magicmark]

@magicmark You may merge this as-is and the follow up with your own edits

++ I'm going to do this.

I think a good strategy (as we discussed) would be to introduce the concept in the RFC document (README.md?) and then fully spec it out in spec markdown files in the same folder.

Getting started on this now!

For now i'll be able to build the spec markdown html locally - what do you think about adding a build action in this repo to individually build+host spec markdown directories? e.g. we'd deploy something like https://rfcs.graphql.org/AbstractFilter.html

[magicmark]

some meta-context - this proposal is not to change the core language of GraphQL

This is indented to be supplementary: a "userland" or "contrib" spec. (Prior art includes the connections and global objects specification).

The idea of submitting this as an RFC is similar to that of Python's PEPs, which may cover non-core-language things such as formatting.

By hosting these in the graphql/graphql-wg repo, we can:

• provide a point of centralized visibility for a wider audience
• todo: insert note about the benefit of code written in a foundation owned repo, something something cla.

Since strawman RFCs can be merged with minimal review, there should be little barrier to entry for this.

[benjie]

Thanks for writing that up @magicmark; I've written a bit of a proposal here: #1879 feel free to weigh in on it (even though it's tagged "TSC discussion" it's not private, we have a separate repo for that) with your own thoughts e.g. your PEP-like suggestions.

[magicmark]

@benjie thoughts on if this spec should also support a field that returns a single type?

e.g. this could still be useful even when returning a single type

interface BannerAd { ... }
type FlashGameAd implements BannerAd { ... }
type InteractiveHTMLCanvasAd implements BannerAd { ... }
type StaticImageAd implements BannerAd { ... }

type Query {
  bannerAd(only: String): BannerAd
}

[benjie]

I don't see why not, though bannerAd(only: [String]) still allows for a single type to be specified. I guess you could make it required as a string to enforce exactly one, but then I'd just recommend using separate accessors 🤷‍♂️

[magicmark]

Ah yes I meant bannerAd(only: [String]): BannerAd. I agree it wouldn't make much sense for a single string.

thanks!