Gatsby: Stricter type inference and enforcement?

Created on 1 Aug 2019  路  18Comments  路  Source: gatsbyjs/gatsby

Is there a way to assume that every field seen in a frontmatter is non-nullable? It seems like that would be a reasonable option to have.

I solved it like this,

exports.createSchemaCustomization = ({ actions }) => {
   const { createTypes } = actions;
   const typeDefs = `
    type Frontmatter {
      title: String!
      date(formatString: String fromNow: Boolean difference: String locale: String): Date!
      description: String!
      tags: [String!]!
    }

    type MarkdownRemark implements Node {
      html: String!
      frontmatter: Frontmatter!
    }
  `;
   createTypes(typeDefs);
};

Which is fine.

But, it all works except for the html field which still ends up being nullable. Why? And, I'm not even sure why that is nullable in the first place. In what situation would the html be null?

Also, will this schema be enforced in any way? If one of my blog posts, for example, are missing a date field will the CLI yell at me? I'm using this with graphql codegen for convenience, but that would be nice too.

Thanks

GraphQL

Most helpful comment

This is still a problem.

All 18 comments

@deklanw

  • Gatsby v2.2 has introduced new schema-related APIs like the createTypes action, but many plugins are still relying on the setFieldsOnGraphQLNodeType API, which - while not officially deprecated - will just overwrite user-provided field-types. see here for the html field
  • slightly unrelated: you can put the dateformat directive on the Frontmatter.date field so you don't have to manually state all those input args: date: Date! @dateformat

@stefanprobst

That explains the html thing. Thanks for the date tip. I'm still wondering why html is nullable to begin with, and whether these types get enforced via CLI complaining at me.

yes would probably make sense to make it not nullable.
if you want you can enforce this yourself with the createResolvers API, which is run as the last step in schema generation (i.e. after setFieldsOnGraphQLNodeType):

// gatsby-node.js
exports.createResolvers = ({ createResolvers }) => {
  createResolvers({
    MarkdownRemark: {
      html: {
        type: 'String!',
      }
    }
  })
}

GraphQL will complain when there are null values on GraphQLNonNull fields. You can check the error you'll see with something like this:

const { graphql, buildSchema } = require('graphql')
graphql(
  buildSchema('type Query { html: String! }'),
  'query { html }'
).then(result => console.error(result.errors))

Hi everyone. I'm with the author, many fields like timeToRead and html and mostly all others are optional and it drives me nuts a little :)

Why? Because I'm full-blown on TypeScript and https://graphql-code-generator.com/ and it's indeed much easier to navigate all those deep trees of nodes, edges, JSON files, and other things when it's strongly typed, also, it's nice to be sure that everything is nicely typed and "there" and of a correct type based on typings generated from the schema, queries, fragments etc.

Basically, the fact that 99% of the fields in remark types are optional whether they are not, makes it hell on earth for 100% TS typed Gatsby sites with LOTS of null checks. Also, types like [String] is even worse, not only an array part needs null check but also all elements inside while in real life it almost never they will be nullable.

So, I will be super happy if the types that plugins are generating will become stricter.

@RIP21
Yes, that is my motivation for this post also.

@stefanprobst Can we get this tagged properly maybe? So it will be in backlog or so? Because it's kinda painful :)

Not stale, still pain.

This is still a problem.

New to Gatsby and have been running into this too - it's definitely painful for TS sites!

Hiya!

This issue has gone quiet. Spooky quiet. 馃懟

We get a lot of issues, so we currently close issues after 30 days of inactivity. It鈥檚 been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 馃挭馃挏

Hey again!

It鈥檚 been 30 days since anything happened on this issue, so our friendly neighborhood robot (that鈥檚 me!) is going to close it.
Please keep in mind that I鈥檓 only a robot, so if I鈥檝e closed this issue in error, I鈥檓 HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community! 馃挭馃挏

It's not stale. Thanks.

We're moving official plugins to use the schema customization API like @stefanprobst mentioned. For now, you can do it yourself in gatsby-node.js. It's still going to be impossible to do this correctly 100% of the time. We could use inference and if a property is available everywhere mark it as non nullable.

cc @vladar

Yes, you can follow #20069 for schema customization updates. We will try to convert as much as possible to non-null as a part of this process.

Hiya!

This issue has gone quiet. Spooky quiet. 馃懟

We get a lot of issues, so we currently close issues after 30 days of inactivity. It鈥檚 been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 馃挭馃挏

Hiya!

This issue has gone quiet. Spooky quiet. 馃懟

We get a lot of issues, so we currently close issues after 30 days of inactivity. It鈥檚 been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 馃挭馃挏

Not stale, dear bot.

I'll close this in favor of https://github.com/gatsbyjs/gatsby/issues/20069 as the original question was answered and nothing actionable is present. We'd be happy to receive PRs to update the plugins to use the stricter variant :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

benstr picture benstr  路  3Comments

dustinhorton picture dustinhorton  路  3Comments

hobochild picture hobochild  路  3Comments

totsteps picture totsteps  路  3Comments

rossPatton picture rossPatton  路  3Comments