Skip to main content

Fragment Modularity

At a glance​

Timeline​

See This RFC for more details: https://github.com/graphql/graphql-wg/blob/main/rfcs/FragmentModularity.md

In an ideal world, fragments would be so modular that our validation rules would be inductive: if Query Q depends on Fragment B and C, then so long as we know fragments B and C are valid, and we run validation on Q against B and C's type declarations (i.e. just the fragment B on Foo portion of the fragment definition, the stuff before the selection set brackets { ... }), then we know Q is valid.

I'm hoping this discussion helps us clarify the work required to set us in that direction, and makes sure related projects, like Client Controlled Nullability, are at least compatible with this evolution.

Currently I see three different "solution spaces" for addressing this problem:

Personally, I'm of the opinion that the metadata approach is a cudgel: it might give clients some hooks to help solve client-specific problems, but doesn't give us a clear path towards solving other, related problems like Error Boundaries. So I'm more focused on the other two paths: my favored approach would be one where you could safely opt-in to everything being modular.

To get the discussion started, cc @josephsavona @captbaritone @hwillson @twof who have all explicitly expressed interest in this area.