Allow blocks usage pattern compatible with codegen

[mrclay]

I'm trying to add TypeScript support to the "blocks-support" example, and finding that the proposed example of specifying fragments from @faustwp/blocks is not compatible with codegen.

https://github.com/wpengine/faustjs/blob/0759959fa4949abe9835afa28e9ff34f795cc632/examples/next/block-support/wp-templates/front-page.js#L24-L35

Codegen is able to read fragments from constants defined in the project, but apparently not from an 3rd party package. It doesn't choke, it just silently ignores the query and no GetPageQuery type is generated. Arguably this could be a bug with codegen's parser, but I don't think it's a fixable one without having their parser reach into modules and navigate/execute code.

I suggest the @faustwp/blocks package have a way to generate a wp-core-block-fragments.ts file that uses a codegen-compatible syntax like:

import { gql } from '../__generated__';

export const CORE_HEADING_BLOCK_FRAGMENT = gql(`
  fragment CoreHeadingFragment on CoreHeading {
  ...
  }
`);

export const CORE_PARAGRAPH_BLOCK_FRAGMENT = gql(`
  fragment CoreParagraphFragment on CoreParagraph {
  ...
  }
`);

In some projects we've just used a single fragment for blocks:

export const BLOCKS_FRAGMENT = gql(`
  fragment BlocksFragment on PageEditorBlock {
    __typename
    name
    renderedHtml
    id: clientId
    parentId: parentClientId
    ... on CoreHeading {
      more here...
    }
    ... on CoreParagraph {
      more here...
    }
  }
`);

[mrclay]

Quick and dirty script for this: https://gist.github.com/mrclay/f1a949d1be18a44281a1556fe2765971

[jan-clockworkwp]

@mrclay thanks for your script. I was facing the same problem and solved it in similar way, but I have never (not even with your script) been able to make graphql-codegen script work with queries/fragments using inline variables like in the official example https://github.com/wpengine/faustjs/blob/0759959fa4949abe9835afa28e9ff34f795cc632/examples/next/block-support/wp-templates/front-page.js#L24-L35 but instead I was forced to write all blocks fragments inline, like this:

editorBlocks {
    name
    __typename
    renderedHtml
    id: clientId
    parentId: parentClientId
    ...CoreButtonBlockFragment
    ...CoreButtonsBlockFragment
    ...CoreCodeOverrideBlockFragment
    ...CoreColumnBlockFragment
    ...CoreColumnsBlockFragment
    ...CoreHeadingBlockFragment
    ...CoreImageBlockFragment
    ...CoreListBlockFragment
    ...CoreParagraphBlockFragment
    ...CoreQuoteBlockFragment
    ...CoreSeparatorBlockFragment
}

Were you able to use template string queries/fragments with graphql-codegen? Thanks!

[mrclay]

@jan-clockworkwp We updated this https://gist.github.com/mrclay/f1a949d1be18a44281a1556fe2765971 and we had to keep our fragments in separate modules so the script wouldn't import a ton of React code with CSS, etc.

[jan-clockworkwp]

@mrclay nice one! Thanks for an update. One additional question, to learn something new everyday, if you don't mind. How do you run your .ts script file? Are you using ts-node or more sophisticated approach? Cheers!

[mrclay]

@jan-clockworkwp Yes, using ts-node. I've just updated it to allow components using innerBlocks.

[jan-clockworkwp]

@mrclay thanks a lot for confirming that. I really appreciated you script, saved me a lot of time. If I could suggest one small improvement to your script to make it work with flatToHierarchical method as well in faustjs context and simply just map values clientId and parentClientId to id and parentId as described in oficial docs in your output fragment file. Otherwise it works fabulously, thanks for sharing it with the community. Let's see if it gets to Faust official package any soon.

[moonmeister]

We'll be addressing this in a new implementation of Blocks support. stay tuned.