[gatsby-source-wordpress] Get (flexible content) fields for multiple post types

[haroldangenent]

I think there are no issues opened on this subject, so here it goes.

Summary

I want to query flexible content fields from a WordPress post type. Using the provided link, this is quite easy. I just use a query similar to this (simplified without using variables for retrieval):

wordPressWpPost {
  acf {
    content_post {
      etcetera..
    }
  }
}

Now let's say I have a load of different field types, making this query quite long. Now, the same fields are used on several post types. They have (some) different fields, but all have the same 'flexible content' field. I want to query them all in the same way, so I don't have to copy and paste this long list of flexible content types for all post types. On the React side of things, the same component that handles the different blocks is used.

Ideally, the query would look something like this:

wordPressWpPost {
  title
  ...ContentFields
}

wordPressWpEvent {
  date
  ...ContentFields
}

wordPressWpPage {
  title
  maybeAnotherField
  ...ContentFields
}

The obvious solution would be using a fragment. Something like this:

fragment ContentFields on wordpress__wp_post {
    acf {
      content_post {
        ... long list of field types
      }
  }
}

However, this fragment would only work for the type wordpress__wp_post and the field content_post. Is there any way to make this fragment's content dynamic? String interpolation seems impossible for GraphQL queries.

Maintaining a 'static' fragment per type would seem quite impossible for 10+ field types, especially when creating new ones. I've looked into a bunch of options, but I cannot seem to find the right approach. Is this possible and does anyone have a great tip on where to start?

Relevant information

• Flexible content gatsby-source-wordpress

Environment (if relevant)

  System:
    OS: macOS High Sierra 10.13.6
    CPU: x64 Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 9.4.0 - /usr/local/bin/node
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 69.0.3497.100
    Firefox: 58.0.2
    Safari: 12.0
  npmPackages:
    gatsby: 2.0.11 => 2.0.11
    gatsby-image: 2.0.5 => 2.0.5
    gatsby-plugin-emotion: ^2.0.5 => 2.0.5
    gatsby-plugin-manifest: ^2.0.2 => 2.0.2
    gatsby-plugin-offline: ^2.0.5 => 2.0.5
    gatsby-plugin-react-helmet: ^3.0.0 => 3.0.0
    gatsby-plugin-sharp: ^2.0.5 => 2.0.5
    gatsby-plugin-typography: ^2.2.0 => 2.2.0
    gatsby-source-wordpress: ^3.0.1 => 3.0.1
    gatsby-transformer-sharp: 2.1.2 => 2.1.2
  npmGlobalPackages:
    gatsby-cli: 2.4.1

File contents (if changed)

gatsby-config.js: N/A
package.json: N/A
gatsby-node.js: N/A
gatsby-browser.js: N/A
gatsby-ssr.js: N/A

[pieh]

Can you create fragment for flexible content type instead of fragments for each types that can be used?

[haroldangenent]

@pieh I'm not sure what you mean. What I'm trying to do is create one fragment that can be used for all types. In the example above it's called ContentFields.

Fragment per type

Another option would be to create "fragments" per flexible content type, as such for two types of blocks:

fragment ContentTypeText on WordPressAcf_text {
  title
  content
  etc..
}

fragment ContentTypeImage on WordPressAcf_image {
  image {
    etc..
  }
}

And then per content type:

wordPressWpPage {
  title
  maybeAnotherField
  acf {
    content {
      __typename
      ... on WordPressAcf_text {
        ...ContentTypeText
      }
      ... on WordPressAcf_image {
        ...ContentTypeImage
      }
    }
  }
}

This would make the 'per type' part quite verbose (and not DRY), especially when you have 5 or 10 content types who all benefit from this flexible content field. It would still be very easy to 'forget' adding this to all 5-10 types when you create a new type of flexible content block.

Would there be any way of making this non-repetitive, since we always need to change this when the content types change?

[pieh]

What about something like:

fragment ContentType on <NameOfContentFieldType> {
  __typename
  ... on WordPressAcf_text {
    fields
  }
  ... on WordPressAcf_image {
    fields
  }
}

and then

wordPressWpPage {
  title
  maybeAnotherField
  acf {
    content {
      ...ContentType
    }
  }
}

[haroldangenent]

Yes, that would be great and is exactly what I've been poking around with. However, I cannot find <NameOfContentFieldType>. This seems to be generated inside the WordPress source plugin and becomes something like unionContentPostNodeWordPressAcfImageWordPressAcfText_2 and is different per content type and changes a lot (when content changes, when compilation changes).

[pieh]

Ah, you are right of course. Unfortunately there is way of doing this right now, so you need to do this as You are doing right now :/

We plan on adding more control for users for schema generation (so you could force type name for content field) - #4261, but it won't be done soon

[haroldangenent]

Okay, that's too bad. Thanks for your quick response however.

Theoretically, would it be an idea to 'share' GraphQLUnionType instances when the same nodes are linked instead of incrementing the suffix for every encountered union type? Or does that sound generally like a bad idea for other use-cases?

[haroldangenent]

This was fixed in #9052. Thanks again for your help @pieh!

You can now use this notation: #8615 (comment), where <NameOfContentFieldType> is union<fieldKey>Node_2. In the example, it would be: unionContentNode_2.