feat: add path field to nested docs plugin

[Livog]

Description

I propose the introduction of a new 'path' field for the nested docs plugin, that enables developers to query documents across multiple collections using a single field. This field can be configured as either unique or non-unique across collections and is opt-in to suit specialized needs.

This feature emerged from the need for a simpler way to query documents, as well as the limitations encountered with the 'breadcrumbs' field, particularly when trying to query paths with repeated segments like /pages/pages/page and when querying against the breadcrumbs array proved challenging. To address this, the 'path' field allows to query directly against 1 collection using 1 field or creating a custom endpoint that query two collections simultaneously. This feature is especially useful when the same 'content' field, such as blocks or content (Rich Text), is used across multiple collections to display content.

Here is an integration example with a Next.js project using the App Router:

// app/[[...path]]/page.tsx
const { docs } = await payload.find({
    collection: 'pages',
    where: { path: { equals: path } },
    depth: 3
});
const page = docs?.at(0) || null

This setup highlights the ease of fetching your content in a single dynamic route, adding onto a simpler developer experience.

For context, here is an example of the current method of querying documents using the 'breadcrumbs' field:

const results = await payload.db.collections['pages'].aggregate([
    {
      $match: {
        'breadcrumbs.url': path
      }
    },
    {
      $addFields: {
        lastBreadcrumb: { $arrayElemAt: ['$breadcrumbs', -1] }
      }
    },
    {
      $match: {
        'lastBreadcrumb.url': path
      }
    }
]);

While effective, the current method using 'breadcrumbs' does not allow for preemptive blocking of the save action if the prospective path conflicts with or already exists. The new 'path' field addresses this issue by enabling conflict checks before saving, ensuring unique navigation paths. Additionally, if you use the breadcrumbs way of querying the developers often need to query twice to utilize Payload's built-in depth feature for fetching relational fields.

The introduction of the 'path' field not only simplifies querying across collections but should also be enhancing link management with the lexical LinkFeature as you can use the path field.

• I have read and understand the CONTRIBUTING.md document in this repository.

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Checklist:

• I have added tests that prove my fix is effective or that my feature works
• Existing test suite passes locally with my changes
• I have made corresponding changes to the documentation

[jmikrut]

Hey @Livog we'll take a look at this ASAP and get back to you!