Feature request: Guilliotine should take nullability into account

Features
1

:information_source: This problem was first posted as a comment in another feature request.

Nullability

A lot of fields from Guillotine that in reality is not nullable (e.g displayName), does not use nonNull() in Guillotine, resulting in more complex types then necessary.

Similarly fields in content types where <occurrences minimum="1"/> should result in a GraphQL-type that is not nullable.

The problem for me is when I run TypeScript-code generation like described here, I get types back that are much more difficult to work with, then if they were not nullable.

Example

The “null | undefined” type is in reality not true for displayName, so we are making this a lot more difficult to program against then it should be.

export type ContentByPathQuery = {
  __typename?: 'Query'
  guillotine?:
    | {
        __typename?: 'HeadlessCms'
        get?:
          | { __typename?: 'base_Folder'; displayName?: string | null | undefined }
          | { __typename?: 'base_Media'; displayName?: string | null | undefined }
          | { __typename?: 'base_Shortcut'; displayName?: string | null | undefined }
          | { __typename?: 'base_Structured'; displayName?: string | null | undefined }
          | { __typename?: 'base_Unstructured'; displayName?: string | null | undefined }
          | { __typename?: 'media_Archive'; displayName?: string | null | undefined }
          | { __typename?: 'media_Audio'; displayName?: string | null | undefined }
          | { __typename?: 'media_Code'; displayName?: string | null | undefined }
          | { __typename?: 'media_Data'; displayName?: string | null | undefined }
          | { __typename?: 'media_Document'; displayName?: string | null | undefined }
          | { __typename?: 'media_Executable'; displayName?: string | null | undefined }
          | { __typename?: 'media_Image'; displayName?: string | null | undefined }
          | { __typename?: 'media_Presentation'; displayName?: string | null | undefined }
          | { __typename?: 'media_Spreadsheet'; displayName?: string | null | undefined }
          | { __typename?: 'media_Text'; displayName?: string | null | undefined }
          | { __typename?: 'media_Unknown'; displayName?: string | null | undefined }
          | { __typename?: 'media_Vector'; displayName?: string | null | undefined }
          | { __typename?: 'media_Video'; displayName?: string | null | undefined }
          | {
              __typename?: 'com_nerdforge_Article'
              displayName?: string | null | undefined
              data?:
                | {
                    __typename?: 'com_nerdforge_Article_Data'
                    intro?:
                      | { __typename?: 'RichText'; processedHtml?: string | null | undefined }
                      | null
                      | undefined
                  }
                | null
                | undefined
            }
          | { __typename?: 'portal_Fragment'; displayName?: string | null | undefined }
          | { __typename?: 'portal_PageTemplate'; displayName?: string | null | undefined }
          | { __typename?: 'portal_Site'; displayName?: string | null | undefined }
          | { __typename?: 'portal_TemplateFolder'; displayName?: string | null | undefined }
          | null
          | undefined
      }
    | null
    | undefined
}
2

I really want to recommend this YouTube video where Eric Normand talks about corner cases (like unnecessary nullability).

It is a short video and worth the look!

3

Hi Tom.

Your request here is based on a misconseption that some fields - like displayName are always required. This is only true when the content is “valid”. Content must be valid before you can publish it.

For example, when you are working with drafts, any required field may be missing - but you can still save the content, and it must still be accessible via API - for instance for previewing.

Essentially, you must handle this “corner case” in your templates, at least if you intend to support previewing.

4

Hi Thomas,

You are if course completely correct about invalid content. Thanks for taking the time consider it! :slight_smile: