plugin-nested-docs: Overrides or Custom?

[58bits]

trafficstars

Nice plugin.

I was experimenting with this a little today and I wasn't able to get the Overrides option to work - at least as far as I could tell. Following the docs when I tried to place the Breadcrumbs and Parent field overrides in the collection definition - I was getting duplicate parent and breadcrumb fields.

In the end what worked was to define the plugin configuration like this...

 plugins: [
    nestedDocs({
      collections: ['docs'],
      parentFieldSlug: 'parent',
      breadcrumbsFieldSlug: 'breadcrumbs',
      generateLabel: (_, doc: any) => doc.title,
      generateURL: docs => docs.reduce((url, doc) => `${url}/${doc.slug}`, ''),
    }),
  ],

And then use createParentField createBreadcrumbsField helper methods to create the fields in the collection definition - and all worked well.

Not sure if this made a difference, but the breadcrumbs field is in a tab (whereas the parent field is in the sidebar).

I'll experiment a little more and see if I can reproduce this in the demo collection of this repo.

Here's the collection definition...

const Docs: CollectionConfig = {
  slug: 'docs',
  admin: {
    defaultColumns: ['title', 'author', 'parent', '_status'],
    useAsTitle: 'title',
  },
  versions: {
    drafts: true,
  },
  access: {
    create: isAdminOrEditor,
    read: publishedOnly,
    readVersions: isAdminOrEditor,
    update: isAdminOrEditor,
    delete: isAdmin,
  },
  fields: [
    {
      type: 'tabs',
      tabs: [
        {
          label: 'Details',
          fields: [
            {
              name: 'title',
              type: 'text',
              localized: true,
              required: true,
            },
            {
              name: 'author',
              type: 'relationship',
              relationTo: 'users',
            },
            availableTranslationsField(),
            createBreadcrumbsField(
              // First argument is equal to the slug of the collection
              // that the field references
              'docs',

              // Argument equal to field overrides that you specify,
              // which will be merged into the base `breadcrumbs` field config
              {
                label: 'Breadcrumbs',
              },
            ),
          ],
        },
        {
          label: 'Media',
          fields: [
            {
              name: 'featureImage',
              type: 'upload',
              relationTo: 'media',
            },
          ],
        },
        {
          label: 'Content',
          fields: [
            {
              name: 'content',
              type: 'blocks',
              blocks: [Content, MediaBlock, Banner, Code, Markdown],
              required: true,
            },
          ],
        },
      ],
    },
    slugField(),
    {
      name: 'publishedOn',
      type: 'date',
      required: true,
      defaultValue: () => new Date(),
      admin: {
        date: {
          pickerAppearance: 'dayAndTime',
        },
        position: 'sidebar',
      },
    },
    createParentField(
      // First argument is equal to the slug of the collection
      // that the field references
      'docs',

      // Second argument is equal to field overrides that you specify,
      // which will be merged into the base parent field config
      {
        admin: {
          position: 'sidebar',
        },
        // Note: if you override the `filterOptions` of the `parent` field,
        // be sure to continue to prevent the document from referencing itself as the parent like this:
        // filterOptions: ({ id }) => ({ id: {not_equals: id }})`
      },
    ),
  ],
}

Thanks again for this and the cool work on Payload CMS

[58bits]

I just tested the demo project, and while there's a high probability I've messed something up - when testing the override feature I was getting a duplicate breadcrumbs field.

I think there might be some dependency issues as well. After updating components I needed to update the payload init to...

await payload.init

...as opposed to..

await payload.initAsync

Hope some of this helps.

If I have more time I'll dig a little further.

[DanRibbens]

Related: https://github.com/payloadcms/payload/issues/3690