A Component Proposal

[timofei-iatsenko]

I would like to introduce a concept of a Components into Payload CMS.

This is effectively just a definition of Type in graphql or Class in Typescript.

Despite the fact we can benefit from dev-ops vs click-ops approach and extract some common fields of collection/global type into separate file and reuse it, this relation isn't reflected in GraphQL or Typescript types. Which make impossible to use some common approaches, especially in GraphQL.

Let me show this by examples:

This is how it is now:

const MetaFields: Field[] = [
  {
    name: 'metaDescription',
    type: 'text',
  },
  {
    name: 'metaTitle',
    type: 'text',
  }
]

const Pages: CollectionConfig = {
  slug: 'pages',
  fields: [
    ...MetaFields,
    // other Page  fields
  ],
};


const Categories: CollectionConfig = {
  slug: 'categories',
  fields: [
    ...MetaFields,
    // other Category fields
  ],
};

# GraphQL
type Page {
  metaDescription: String
  metaTitle: String
}

type Category {
  metaDescription: String
  metaTitle: String
}

The developers may want to create a common component on the page called Meta to consume this data:

gql`
 fragment MetaFragment on Page { // <-- Problem is here
  heroImage
  heroText
}
`
type Props = {
  meta: MetaFragment,
}

export const Hero = (props: Props) => { /* ... */} 

In GQL you can select fields only from one type, you cannot spread fragment on different types even if listed fields exist on both types. So i can use this component with it's fragment only on Page type and it's difficult to reuse it for Category

Proposition:

const MetaTagsComponent: ComponentConfig = {
  name: 'MetaTags',
  fields: [
    {
      name: 'metaDescription',
      type: 'text',
    },
    {
      name: 'metaTitle',
      type: 'text',
    }
  ]
}

const Pages: CollectionConfig = {
  slug: 'pages',
  fields: [
    {
      name: 'meta',
      type: 'component',
      component: MetaTagsComponent,
    },
  ],
};


const Categories: CollectionConfig = {
  slug: 'categories',
  fields: [
    {
      name: 'meta',
      type: 'component',
      component: MetaTagsComponent,
    },
  ],
};

# GraphQL
type MetaTags {
  metaDescription: String
  metaTitle: String
}

type Page {
  meta: MetaTags
}

type Category {
  meta: MetaTags
}

Then you can query it using one component from different collections:

gql`
 fragment MetaFragment on MetaTags {
  heroImage
  heroText
}
`
type Props = {
  hero: MetaFragment,
}

export const Hero = (props: Props) => { /* ... */} 

// index.page.ts
const pageQuery = gql`
  query IndexPageQuery {
    category {
      meta {
        ...MetaTagsFragment
      }
    }

    page {
      meta {
        ...MetaTagsFragment
      }
    }
  }
`;

Basically, it's quite similar to blocks, but singular.

Thanks.

Related issues:

• Incorrect (?) union types in GraphQL schema #2603

[jmikrut]

@thekip just writing here quickly to say that I love it. This needs to happen ASAP. I will report back with more but will mark it as planned in the interim!

[jmikrut]

Just an update here - we're marking this as priority 1 on our roadmap and have a very good way to support this.

With our i18n changes, we've implemented a way to assign a deliberate TypeScript interface name, as well as a deliberate GraphQL type name. With these two approaches, we could easily assume that if there are two fields / collections / blocks / etc. with the same TS / GraphQL name, they should be treated as the same type. And then we could create / re-use that type accordingly.

Super easy way to support this feature without having to build additional config properties!

[timofei-iatsenko]

Sounds like easier for implementing, but not easier to understanding and using. How the case above supposed to look in this implementation?

[itzaks]

I'm also curious on how to do this. I'm trying to create a reusable field that creates a Group-field that always carries a boolean-field and a text-field. But my graphql scheme is telling me that each group has its own type, would be great to specify an interface that can be used for fragments. I'm thinking that this is what the i18n-changes can open up for? Right?

Here's my idea:

const approvable = (name: string, field: ApprobableField): Field => ({
  name,
  type: 'group',
  fields: [
    {
      name: 'isApproved',
      type: 'checkbox'
    },
    field
  ],
})

Then used like

  ...
  fields: [
    {
      name: 'name',
      type: 'text',
      required: true,
    },
    approvable('description', {
      name: 'data',
      type: 'text',
    }),
    approvable('ideas', {
      name: 'data',
      type: 'text',
    }),
  ]
  ...

Each type generated by the approvable is unique, so it makes using fragments a little complicated.

Any ways to achieve this? Love the work on payload by the way.

[ssyberg]

Is this the "preferred" method of getting "inheritance" out of Payload? It's very common for us to define what I would normally call a "base collection" and then ideally we'd inherit not just the fields, but the admin options from that base collection.

[JarrodMFlesch]

Hey @thekip I just opened a PR to address this request. Could you give it a look and let me know what you think? Much appreciated 👍

Related PR

[DanRibbens]

Released as of https://github.com/payloadcms/payload/releases/tag/v1.8.4

[itzaks]

Awesome. Great work!