We're building more and more with useFragment and for the most part are pretty happy with it. Something that comes up frequently as a footgun, though, is folks forgetting to add variables to their useFragment calls. This can disrupt the development cycle in multiple ways:
During development, someone adds a component with a fragment depending on variable and a new useFragment call, and in local testing data never appears (because they forgot to wire in the variable). Usually generates a dev support request.
During development, a field that needs a variable is added to an existing fragment, but the variable is never wired in. But because the test harness calls cache.writeFragment with no variables to bootstrap the test, tests pass and the experience ships broken.
Ideally, we could catch many of these cases with a document-aware lint rule, but some cases are trickier to lint (like when test fragments are defined in a test file but passed to a utility bootstrapping the test that programmatically calls cache.writeFragment).
I haven't worked with TypedDocumentNode enough to know if this is something TypeScript could help guard against either, but that would be even better than a lint rule.
As a fallback, would it be prohibitively expensive to scan fragment ASTs at runtime to warn or error when a var appears in a fragment but isn't passed to any of the APIs that accept fragments as arguments? As @jerelmiller mentioned in a side discussion, it's possible doing this in a dev-only check might be sufficient to ensure that tests fail.
We're building more and more with
useFragment
and for the most part are pretty happy with it. Something that comes up frequently as a footgun, though, is folks forgetting to add variables to theiruseFragment
calls. This can disrupt the development cycle in multiple ways:useFragment
call, and in local testing data never appears (because they forgot to wire in the variable). Usually generates a dev support request.cache.writeFragment
with no variables to bootstrap the test, tests pass and the experience ships broken.Ideally, we could catch many of these cases with a document-aware lint rule, but some cases are trickier to lint (like when test fragments are defined in a test file but passed to a utility bootstrapping the test that programmatically calls
cache.writeFragment
).I haven't worked with TypedDocumentNode enough to know if this is something TypeScript could help guard against either, but that would be even better than a lint rule.
As a fallback, would it be prohibitively expensive to scan fragment ASTs at runtime to warn or error when a var appears in a fragment but isn't passed to any of the APIs that accept fragments as arguments? As @jerelmiller mentioned in a side discussion, it's possible doing this in a dev-only check might be sufficient to ensure that tests fail.