scottrippey commented 5 months ago

What

Previously, there were actually 3 ways we can bypass validation and infer the result type:

q.project({
  name: true,
  name2: "name",
  name3: q.field("name"),
})

However, it's really hard to understand that this syntax results in bypassing runtime validation. Instead, this PR adds the q.infer() method, which can be used in place of validation methods like q.string(). Using q.infer() is the only way to bypass runtime validation. Example:

q.project({
  name: q.infer(),
  name2: ["name", q.infer()],
  name3: q.field("name", q.infer()),
});

Benefits:

Makes it easier to see when runtime validation is bypassed
Easier to document this behavior, by documenting q.infer() instead of documenting these 3 different syntaxes
Teams can use an eslint rule to prevent q.infer(), if they want to enforce 100% runtime validation

Drawbacks:

More verbose, if your project doesn't use runtime validation

vercel[bot] commented 5 months ago

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

scottrippey commented 5 months ago

Closing this PR. I've reverted these changes, in favor of a different approach (a validationRequired: true flag)

FormidableLabs / groqd

groq-builder: use `q.infer()` syntax #258

What