OneGraph and Graphql Codegen produce enums with numerical representations

Question

OneGraph and Graphql Codegen produce enums with numerical representations

After migrating my project's codebase from using the direct Headless Wordpress GraphQL endpoint to OneGraph for Google+Facebook Business support, I encountered an error related to apollo referencing the output codegen. Here is the specific error message:

  graphQLErrors: [
    {
      message: 'Variable "$idTypeFoot" got invalid value 2; Expected type MenuNodeIdTypeEnum.',
      path: [Array],
      extensions: [Object]
    },
    {
      message: 'Variable "$idTypeFoot" got invalid value 2; Expected type MenuNodeIdTypeEnum.',
      path: [Array],
      extensions: [Object]
    }
  ],

The generated/graphql.tsx file contains the output codegen definition as follows:


export enum WordpressMenuNodeIdTypeEnum {
    /** Identify a menu node by the Database ID. */
    DATABASE_ID = 0,
    /** Identify a menu node by the (hashed) Global ID. */
    ID = 1,
    /** Identify a menu node by it's name */
    NAME = 2
}

Prior to the migration to OneGraph, the enum was defined like this:


/** The Type of Identifier used to fetch a single node. Default is "ID". To be used along with the "id" field. */
export enum MenuNodeIdTypeEnum {
    /** Identify a menu node by the Database ID. */
    DatabaseId = 'DATABASE_ID',
    /** Identify a menu node by the (hashed) Global ID. */
    Id = 'ID',
    /** Identify a menu node by its name */
    Name = 'NAME'
}

The dynamic-nav-fields.graphql partial used in the parent query:

fragment DynamicNavFragment on WordpressMenuItem {
    id
    label
    path
    parentId
}

The parent query in dynamic-nav.graphql:

# import DynamicNavFragment from './Partials/dynamic-nav-fields.graphql'

query DynamicNav(
  $idHead: ID!
  $idTypeHead: WordpressMenuNodeIdTypeEnum!
  $idFoot: ID!
  $idTypeFoot: WordpressMenuNodeIdTypeEnum!
    ) {
    Header: wordpress {
        menu(id: $idHead, idType: $idTypeHead) {
            menuItems(where: { parentId: 0 }) {
                edges {
                    node {
                        ...DynamicNavFragment
                        childItems {
                            edges {
                                node {
                                    ...DynamicNavFragment
                                    childItems {
                                        edges {
                                            node {
                                                ...DynamicNavFragment
                                            }
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }
    Footer: wordpress {
        menu(id: $idFoot, idType: idTypeFoot) {
            menuItems(where: { parentId: 0 }) {
                edges {
                    node {
                        ...DynamicNavFragment
                        childItems {
                            edges {
                                node {
                                    ...DynamicNavFragment
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

The configuration in codegen.yml file is set up like this:

overwrite: true
schema:
  ${WORDPRESS_API_URL_YML}:
    headers:
      Authorization: Bearer ${WORDPRESS_AUTH_REFRESH_TOKEN_YML}
documents: 'graphql/**/*.graphql'
generates:
  graphql/generated/graphql.tsx:
    plugins:
      - typescript:
          constEnums: false
          enumsAsTypes: false          
          numericEnums: true
          futureProofEnums: false
          enumsAsConst: false
          onlyOperationTypes: false
          maybeValue: T | null | undefined
          noExport: false
          enumPrefix: true
          fieldWrapperValue: T
          wrapFieldDefinitions: true
          skipTypename: false
          nonOptionalTypename: false
          useTypeImports: false
          avoidOptionals: true
          declarationKind: 
            input: interface
            type: interface
      - typescript-operations:
          declarationKind:
            input: interface
            type: interface
          avoidOptionals: true
          exportFragmentSpreadSubTypes: true
      - typescript-react-apollo:
          addDocBlocks: true
          reactApolloVersion: 3
          documentMode: documentNodeImportFragments
    config:
      maybeValue: T | null | undefined
      declarationKind:
        input: interface
        type: interface
      documentNodeImportFragments: true
      reactApolloVersion: 3
      withHooks: true
      withHOC: false
      avoidOptionals: true
      withComponent: false
      exportFragmentSpreadSubTypes: true
      addDocBlocks: true
  graphql/graphql.schema.graphql:
    plugins:
      - schema-ast
    config:
      commentDescriptions: true
  graphql/graphql.schema.json:
    plugins:
      - introspection
    config:
      commentDescriptions: true
      
hooks:
  afterAllFileWrite: 
    - prettier --write

I am seeking assistance in resolving why OneGraph replaces the generated Enum values with numbers that Apollo client cannot read. Any insights on how to address this issue would be greatly appreciated.

typescript enums graphql next.js code-generation

Answer 1

Answer №1

In short, the solution is to modify the codegen.yml file and set numericEnums: false:

generates:
  graphql/generated/graphql.tsx:
    plugins:
      - typescript:
          numericEnums: false

To troubleshoot this issue, I analyzed the GraphQL SDL definition of WordpressMenuNodeIdTypeEnum:

enum WordpressMenuNodeIdTypeEnum {
    # Identify a menu node by the Database ID.
    DATABASE_ID
    # Identify a menu node by the (hashed) Global ID.
    ID
    # Identify a menu node by its name
    NAME
}

I compared this with the previous setting of numericEnums: true in codegen.yml, and utilized them on the graphql playground at https://i.stack.imgur.com/OGGkv.png

The screenshot illustrates that the SDL definition was transformed into numeric enums (the standard for typescript enums at runtime)

I then experimented with numericEnums: false: https://i.stack.imgur.com/aNxtT.png

The resulting output reflects the expected behavior, where WordpressMenuNodeIdTypeEnum.Name is equivalent to "NAME", ensuring Apollo obtains the anticipated value rather than the runtime typescript-enum value (2).

Answer 2

In short, the solution is to modify the codegen.yml file and set numericEnums: false:

generates:
  graphql/generated/graphql.tsx:
    plugins:
      - typescript:
          numericEnums: false

To troubleshoot this issue, I analyzed the GraphQL SDL definition of WordpressMenuNodeIdTypeEnum:

enum WordpressMenuNodeIdTypeEnum {
    # Identify a menu node by the Database ID.
    DATABASE_ID
    # Identify a menu node by the (hashed) Global ID.
    ID
    # Identify a menu node by its name
    NAME
}

I compared this with the previous setting of numericEnums: true in codegen.yml, and utilized them on the graphql playground at https://i.stack.imgur.com/OGGkv.png

The screenshot illustrates that the SDL definition was transformed into numeric enums (the standard for typescript enums at runtime)

I then experimented with numericEnums: false: https://i.stack.imgur.com/aNxtT.png

The resulting output reflects the expected behavior, where WordpressMenuNodeIdTypeEnum.Name is equivalent to "NAME", ensuring Apollo obtains the anticipated value rather than the runtime typescript-enum value (2).

Answer 3

Answer №2

UPDATE — shoutout to @sgrove for his amazing help in troubleshooting the problem!

So, I encountered two possible solutions: either overwrite each enum converted from a string value representing the __type before or hardcode these values in. To access the custom enum value, I needed to include the following in my codegen.yml:

config:
    enumValues:
       WordpressMenuNodeIdTypeEnum: '@/types/global-enums#WordpressMenuNodeIdTypeEnum'

This directs the generated code to import the enum definition from @/types/global-enums.ts.

/** Different types of identifier used to fetch a single node. Default is "ID". Should be used with the "id" field. */
export enum WordpressMenuNodeIdTypeEnum {
    /** Identifies a menu node by the Database ID. */
    DatabaseId = 'DATABASE_ID',
    /** Identifies a menu node by the (hashed) Global ID. */
    Id = 'ID',
    /** Identifies a menu node by its name */
    Name = 'NAME'
}

But then, I faced another issue and opted to directly hardcode the NAME value for WordpressMenuNodeIdTypeEnum into my graphql schema:

# import DynamicNavFragment from './Partials/dynamic-nav-fields.graphql'

query DynamicNav($idHead: ID!, $idFoot: ID!) {
    Header: wordpress {
        menu(id: $idHead, idType: {@NAME@}) {
            menuItems(where: { parentId: 0 }) {
                edges {
                    node {
                        ...DynamicNavFragment
                        childItems {
                            edges {
                                node {
                                    ...DynamicNavFragment
                                    childItems {
                                        edges {
                                            node {
                                                ...DynamicNavFragment
                                            }
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }
    Footer: wordpress {
        menu(id: $idFoot, idType: {@NAME@}) {
            menuItems(where: { parentId: 0 }) {
                edges {
                    node {
                        ...DynamicNavFragment
                        childItems {
                            edges {
                                node {
                                    ...DynamicNavFragment
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

Subsequently, I encountered an additional challenge with the apollo cache since both ServicesTopQuery and DynamicNavQuery had a shared top-level wordpress field with the corresponding __typename "WordPressRootQuery."

Here are the codegen definitions for ServicesTopQuery, ServicesTopQueryVariables, DynamicNavQuery, and DynamicNavQueryVariables:


// Codegen definition for ServicesTopQuery and ServicesTopQueryVariables

[...]

And here is some code from pages/index.tsx where DynamicNavQuery data was initially populated but swiftly overwritten by ServicesTopQuery data.

[...]

To address this issue, I consulted the Apollo docs and updated the instantiation of the new InMemoryCache class with the following configuration:

cache: new InMemoryCache({
            typePolicies: {
                Query: {
                    fields: {
                        wordpress: {
                            merge(existing, incoming, { mergeObjects }) {
                                // invoking nested merge functions
                                return mergeObjects(existing, incoming);
                            }
                        }
                    }
                }
            }
        })
    });

By implementing the above change, I was able to prevent existing wordpress field data from being overwritten by incoming wordpress data, effectively resolving the issue at hand. The migration process from a headless WordPress endpoint to a OneGraph endpoint turned out to be more complex than expected, so I wanted to provide a detailed explanation in case others encounter a similar situation in the future.

Answer 4

UPDATE — shoutout to @sgrove for his amazing help in troubleshooting the problem!

So, I encountered two possible solutions: either overwrite each enum converted from a string value representing the __type before or hardcode these values in. To access the custom enum value, I needed to include the following in my codegen.yml:

config:
    enumValues:
       WordpressMenuNodeIdTypeEnum: '@/types/global-enums#WordpressMenuNodeIdTypeEnum'

This directs the generated code to import the enum definition from @/types/global-enums.ts.

/** Different types of identifier used to fetch a single node. Default is "ID". Should be used with the "id" field. */
export enum WordpressMenuNodeIdTypeEnum {
    /** Identifies a menu node by the Database ID. */
    DatabaseId = 'DATABASE_ID',
    /** Identifies a menu node by the (hashed) Global ID. */
    Id = 'ID',
    /** Identifies a menu node by its name */
    Name = 'NAME'
}

But then, I faced another issue and opted to directly hardcode the NAME value for WordpressMenuNodeIdTypeEnum into my graphql schema:

# import DynamicNavFragment from './Partials/dynamic-nav-fields.graphql'

query DynamicNav($idHead: ID!, $idFoot: ID!) {
    Header: wordpress {
        menu(id: $idHead, idType: {@NAME@}) {
            menuItems(where: { parentId: 0 }) {
                edges {
                    node {
                        ...DynamicNavFragment
                        childItems {
                            edges {
                                node {
                                    ...DynamicNavFragment
                                    childItems {
                                        edges {
                                            node {
                                                ...DynamicNavFragment
                                            }
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }
    Footer: wordpress {
        menu(id: $idFoot, idType: {@NAME@}) {
            menuItems(where: { parentId: 0 }) {
                edges {
                    node {
                        ...DynamicNavFragment
                        childItems {
                            edges {
                                node {
                                    ...DynamicNavFragment
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

Subsequently, I encountered an additional challenge with the apollo cache since both ServicesTopQuery and DynamicNavQuery had a shared top-level wordpress field with the corresponding __typename "WordPressRootQuery."

Here are the codegen definitions for ServicesTopQuery, ServicesTopQueryVariables, DynamicNavQuery, and DynamicNavQueryVariables:


// Codegen definition for ServicesTopQuery and ServicesTopQueryVariables

[...]

And here is some code from pages/index.tsx where DynamicNavQuery data was initially populated but swiftly overwritten by ServicesTopQuery data.

[...]

To address this issue, I consulted the Apollo docs and updated the instantiation of the new InMemoryCache class with the following configuration:

cache: new InMemoryCache({
            typePolicies: {
                Query: {
                    fields: {
                        wordpress: {
                            merge(existing, incoming, { mergeObjects }) {
                                // invoking nested merge functions
                                return mergeObjects(existing, incoming);
                            }
                        }
                    }
                }
            }
        })
    });

By implementing the above change, I was able to prevent existing wordpress field data from being overwritten by incoming wordpress data, effectively resolving the issue at hand. The migration process from a headless WordPress endpoint to a OneGraph endpoint turned out to be more complex than expected, so I wanted to provide a detailed explanation in case others encounter a similar situation in the future.

OneGraph and Graphql Codegen produce enums with numerical representations

Answer №1

Answer №2

Similar questions

Set up linter rules that utilize `useEffect` in place of `React.useEffect` (utilizing named export rather than full export)

Customizable mongoDB database collection

Using import statement is mandatory when loading ES Module in TS Node: server/src/index.ts

Ways to invoke a slice reducer from a library rather than a React component

A guide to mocking Prisma using Jest mock functionality

Error message: Parameters are not defined in the Next.js

Is there a way to modify the code so that upon refreshing, only the randomly selected 20 items are displayed without showing the ordered items?

Having trouble getting Tailwind CSS utility classes to work with TypeScript in create-react-app

Exploring domain routing in Next.js with sub-domains

Ways to turn off a TypeScript error across the entire project

Elementary component placed in a single line

Troubleshooting problem with TypeScript and finding/filtering operations

Steps for sorting items from a list within the past 12 hours

Unexpected Secondary Map Selector Appears When Leaflet Overlay is Added

The redirect feature in getServerSideProps may not function properly across all pages

Unsuitable data types in GraphQL - is the configuration faulty?

Messages are not being emitted from the socket

Retrieving data from notifications without having to interact with them (using Firebase Cloud Messaging and React Native)

The art of crafting informative error log messages in Protractor using TypeScript

Exploring the getServerSideProps function in Next.js with a loop