payload 1.15.6 → 2.0.0-beta.0

package/docs/configuration/localization.mdx

@@ -1,146 +0,0 @@
----
-title: Localization
-label: Localization
-order: 50
-desc: Add and maintain as many locales as you need by adding Localization to your Payload config, set options for default locale, fallbacks, fields and more.
-keywords: localization, internationalization, i18n, config, configuration, documentation, Content Management System, cms, headless, javascript, node, react, express
----
-
-Payload features deep field-based localization support. Maintaining as many locales as you need is easy. All localization support is opt-in by default. To do so, follow the two steps below.
-
-### Enabling in the Payload config
-
-Add the `localization` property to your Payload config to enable localization project-wide. You'll need to provide a list of all locales that you'd like to support as well as set a few other options.
-
-**Example Payload config set up for localization:**
-
-```ts
-import { buildConfig } from 'payload/config'
-
-export default buildConfig({
-  collections: [
-    // collections go here
-  ],
-  localization: {
-    locales: [
-      'en',
-      'es',
-      'de',
-    ],
-    defaultLocale: 'en',
-    fallback: true,
-  },
-});
-```
-
-**Here is a brief explanation of each of the options available within the `localization` property:**
-
-**`locales`**
-
-Array-based list of all locales that you would like to support. These strings do not need to be in any specific format. It's up to you to define how to represent your locales. Common patterns are to use two-letter ISO 639 language codes or four-letter language and country codes (ISO 3166‑1) such as `en-US`, `en-UK`, `es-MX`, etc.
-
-**`defaultLocale`**
-
-Required string that matches one of the locales from the array provided. By default, if no locale is specified, documents will be returned in this locale.
-
-**`fallback`**
-
-Boolean enabling "fallback" locale functionality. If a document is requested in a locale, but a field does not have a localized value corresponding to the requested locale, then if this property is enabled, the document will automatically fall back to the fallback locale value. If this property is not enabled, the value will not be populated.
-
-### Field by field localization
-
-Payload localization works on a **field** level—not a document level. In addition to configuring the base Payload config to support localization, you need to specify each field that you would like to localize.
-
-**Here is an example of how to enable localization for a field:**
-
-```js
-{
-  name: 'title',
-  type: 'text',
-  // highlight-start
-  localized: true,
-  // highlight-end
-}
-```
-
-With the above configuration, the `title` field will now be saved in the database as an object of all locales instead of a single string.
-
-All field types with a `name` property support the `localized` property—even the more complex field types like `array`s and `block`s.
-
-<Banner>
-  <strong>Note:</strong><br/>
-  Enabling localization for field types that support nested fields will automatically create localized "sets" of all fields contained within the field. For example, if you have a page layout using a blocks field type, you have the choice of either localizing the full layout, by enabling localization on the top-level blocks field, or only certain fields within the layout.
-</Banner>
-
-<Banner type="warning">
-  <strong>Important:</strong>
-  <br />
-  When converting an existing field to or from `localized: true` the data
-  structure in the document will change for this field and so existing data for
-  this field will be lost. Before changing the localization setting on fields
-  with existing data, you may need to consider a field migration strategy.
-</Banner>
-
-### Retrieving localized docs
-
-When retrieving documents, you can specify which locale you'd like to receive as well as which fallback locale should be used.
-
-##### REST API
-
-REST API locale functionality relies on URL query parameters.
-
-**`?locale=`**
-
-Specify your desired locale by providing the `locale` query parameter directly in the endpoint URL.
-
-**`?fallback-locale=`**
-
-Specify fallback locale to be used by providing the `fallback-locale` query parameter. This can be provided as either a valid locale as provided to your base Payload config, or `'null'`, `'false'`, or `'none'` to disable falling back.
-
-**Example:**
-
-```
-fetch('https://localhost:3000/api/pages?locale=es&fallback-locale=none');
-```
-
-##### GraphQL API
-
-In the GraphQL API, you can specify `locale` and `fallbackLocale` args to all relevant queries and mutations.
-
-The `locale` arg will only accept valid locales, but locales will be formatted automatically as valid GraphQL enum values (dashes or special characters will be converted to underscores, spaces will be removed, etc.). If you are curious to see how locales are auto-formatted, you can use the [GraphQL playground](/docs/graphql/overview#graphql-playground).
-
-The `fallbackLocale` arg will accept valid locales as well as `none` to disable falling back.
-
-**Example:**
-
-```graphql
-query {
-  Posts(locale: de, fallbackLocale: none) {
-    docs {
-      title
-    }
-  }
-}
-```
-
-<Banner>
-  In GraphQL, specifying the locale at the top level of a query will automatically apply it throughout all nested relationship fields. You can override this behavior by re-specifying locale arguments in nested related document queries.
-</Banner>
-
-##### Local API
-
-You can specify `locale` as well as `fallbackLocale` within the Local API as well as properties on the `options` argument. The `locale` property will accept any valid locale, and the `fallbackLocale` property will accept any valid locale as well as `'null'`, `'false'`, `false`, and `'none'`.
-
-**Example:**
-
-```js
-const posts = await payload.find({
-  collection: 'posts',
-  locale: 'es',
-  fallbackLocale: false,
-})
-```
-
-<Banner type="alert">
-  <strong>Tip:</strong><br/>The REST and Local APIs can return all localization data in one request by passing 'all' or '*' as the <strong>locale</strong> parameter. The response will be structured so that field values come back as the full objects keyed for each locale instead of the single, translated value.
-</Banner>

package/docs/configuration/overview.mdx

@@ -1,181 +0,0 @@
----
-title: The Payload Config
-label: Overview
-order: 10
-desc: The Payload config is central to everything that Payload does, from adding custom React components, to modifying collections, controlling localization and much more.
-keywords: overview, config, configuration, documentation, Content Management System, cms, headless, javascript, node, react, express
----
-
-Payload is a _config-based_, code-first CMS and application framework. The Payload config is central to everything that Payload does. It scaffolds the data that Payload stores as well as maintains custom React components, hook logic, custom validations, and much more.
-
-**Also, because the Payload source code is fully written in TypeScript, its configs are strongly typed—meaning that even if you aren't using TypeScript, your IDE (such as VSCode) may still provide helpful information like type-ahead suggestions while you write your config.**
-
-<Banner type="warning">
-  <strong>Important:</strong>
-  <br />
-  This file is included in the Payload admin bundle, so make sure you do not
-  embed any sensitive information.
-</Banner>
-
-## Options
-
-| Option                | Description                                                                                                                                                                   |
-| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `serverURL`           | A string used to define the absolute URL of your app including the protocol, for example `https://example.com`. No paths allowed, only protocol, domain and (optionally) port |
-| `collections`         | An array of all Collections that Payload will manage. To read more about how to define your collection configs, [click here](/docs/configuration/collections).                |
-| `cors`                | Either a whitelist array of URLS to allow CORS requests from, or a wildcard string (`'*'`) to accept incoming requests from any domain.                                       |
-| `globals`             | An array of all Globals that Payload will manage. For more on Globals and their configs, [click here](/docs/configuration/globals).                                           |
-| `admin`               | Base Payload admin configuration. Specify custom components, control metadata, set the Admin user collection, and [more](/docs/admin/overview#admin-options).                 |
-| `localization`        | Opt-in and control how Payload handles the translation of your content into multiple locales. [More](/docs/configuration/localization)                                        |
-| `graphQL`             | Manage GraphQL-specific functionality here. Define your own queries and mutations, manage query complexity limits, and [more](/docs/graphql/overview#graphql-options).        |
-| `cookiePrefix`        | A string that will be prefixed to all cookies that Payload sets.                                                                                                              |
-| `csrf`                | A whitelist array of URLs to allow Payload cookies to be accepted from as a form of CSRF protection. [More](/docs/authentication/overview#csrf-protection)                    |
-| `defaultDepth`        | If a user does not specify `depth` while requesting a resource, this depth will be used. [More](/docs/getting-started/concepts#depth)                                         |
-| `maxDepth`            | The maximum allowed depth to be permitted application-wide. This setting helps prevent against malicious queries. Defaults to `10`.                                           |
-| `indexSortableFields` | Automatically index all sortable top-level fields in the database to improve sort performance and add database compatibility for Azure Cosmos and similar.                    |
-| `upload`              | Base Payload upload configuration. [More](/docs/upload/overview#payload-wide-upload-options).                                                                                 |
-| `routes`              | Control the routing structure that Payload binds itself to. Specify `admin`, `api`, `graphQL`, and `graphQLPlayground`.                                                       |
-| `email`               | Base email settings to allow Payload to generate email such as Forgot Password requests and other requirements. [More](/docs/email/overview#configuration)                    |
-| `express`             | Express-specific middleware options such as compression and JSON parsing. [More](/docs/configuration/express)                                                                 |
-| `debug`               | Enable to expose more detailed error information.                                                                                                                             |
-| `telemetry`           | Disable Payload telemetry by passing `false`. [More](/docs/configuration/overview#telemetry)                                                                                  |
-| `rateLimit`           | Control IP-based rate limiting for all Payload resources. Used to prevent DDoS attacks and [more](/docs/production/preventing-abuse#rate-limiting-requests).                  |
-| `hooks`               | Tap into Payload-wide hooks. [More](/docs/hooks/overview)                                                                                                                     |
-| `plugins`             | An array of Payload plugins. [More](/docs/plugins/overview)                                                                                                                   |
-| `endpoints`           | An array of custom API endpoints added to the Payload router. [More](/docs/rest-api/overview#custom-endpoints)                                                                |
-| `custom`              | Extension point for adding custom data (e.g. for plugins)                                                                                                                     |
-
-#### Simple example
-
-```ts
-import { buildConfig } from "payload/config";
-
-export default buildConfig({
-  collections: [
-    {
-      slug: "pages",
-      fields: [
-        {
-          name: "title",
-          type: "text",
-          required: true,
-        },
-        {
-          name: "content",
-          type: "richText",
-          required: true,
-        },
-      ],
-    },
-  ],
-  globals: [
-    {
-      slug: "header",
-      fields: [
-        {
-          name: "nav",
-          type: "array",
-          fields: [
-            {
-              name: "page",
-              type: "relationship",
-              relationTo: "pages",
-            },
-          ],
-        },
-      ],
-    },
-  ],
-});
-```
-
-#### Full example config
-
-You can see a full [example config](https://github.com/payloadcms/public-demo/blob/master/src/payload.config.ts) in the Public Demo source code on GitHub.
-
-### Using environment variables in your config
-
-We suggest using the `dotenv` package to handle environment variables alongside of Payload. All that's necessary to do is to require the package as high up in your application as possible (for example, at the top of your `server.js` file), and ensure that it can find an `.env` file that you create.
-
-**Add this line to the top of your server:**
-
-```
-require('dotenv').config()
-// ...
-// the rest of your `server.js` file goes here
-```
-
-Note that if you rely on any environment variables in your config itself, you should also call `dotenv()` at the top of your config itself as well. There's no harm in calling it in both your server and your config itself!
-
-**Here is an example project structure w/ `dotenv` and an `.env` file:**
-
-```
-project-name
----- .env
----- package.json
----- payload.config.js
----- server.js
-```
-
-<Banner type="warning">
-  <strong>Important:</strong>
-  <br />
-  If you use an environment variable to configure any properties that are
-  required for the Admin panel to function (ex. serverURL or any routes), you
-  need to make sure that your Admin panel code can access it. [Click
-  here](/docs/admin/webpack#admin-environment-vars) for more info.
-</Banner>
-
-### Customizing & Automating Config Location Detection
-
-Payload is designed to automatically locate your configuration file. By default, it will first look in the root of your current working directory for a file named `payload.config.js` or `payload.config.ts` if you're using TypeScript.
-
-In development mode, if the configuration file is not found at the root, Payload will attempt to read your `tsconfig.json`, and search in the directory specified in `compilerOptions.rootDir` (typically "src").
-
-In production mode, Payload will first attempt to find the config file in the output directory specified in `compilerOptions.outDir` of your `tsconfig.json`, then fallback to the source directory (`compilerOptions.rootDir`), and finally will check the 'dist' directory.
-
-Please ensure your `tsconfig.json` is properly configured if you want Payload to accurately auto-detect your configuration file location. If `tsconfig.json` does not exist or doesn't specify `rootDir` or `outDir`, Payload will default to the current working directory.
-
-#### Overriding the Config Location
-
-In addition to the above automated detection, you can specify your own location for the Payload config file. This is done by using the environment variable `PAYLOAD_CONFIG_PATH`. The path you provide via this environment variable can either be absolute or relative to your current working directory. This can be useful in situations where your Payload config is not in a standard location, or you wish to switch between multiple configurations.
-
-**Example in package.json:**
-
-```json
-{
-  "scripts": {
-    "dev": "PAYLOAD_CONFIG_PATH=path/to/custom-config.js node server.js",
-  }
-}
-```
-
-When `PAYLOAD_CONFIG_PATH` is set, Payload will use this path to load the configuration, bypassing all automated detection.
-
-### Developing within the Config
-
-Payload comes with `isomorphic-fetch` installed which means that even in Node, you can use the `fetch` API just as you would within the browser. No need to import `axios` or similar, unless you want to!
-
-### TypeScript
-
-You can import config types as follows:
-
-```ts
-import { Config } from "payload/config";
-
-// This is the type used for an incoming Payload config.
-// Only the bare minimum properties are marked as required.
-```
-
-```ts
-import { SanitizedConfig } from "payload/config";
-
-// This is the type used after an incoming Payload config is fully sanitized.
-// Generally, this is only used internally by Payload.
-```
-
-### Telemetry
-
-Payload collects **completely anonymous** telemetry data about general usage. This data is super important to us and helps us accurately understand how we're growing and what we can do to build the software into everything that it can possibly be. The telemetry that we collect also help us demonstrate our growth in an accurate manner, which helps us as we seek investment to build and scale our team. If we can accurately demonstrate our growth, we can more effectively continue to support Payload as free and open-source software. To opt out of telemetry, you can pass `telemetry: false` within your Payload config.
-
-For more information about what we track, take a look at our [privacy policy](/privacy).

package/docs/email/overview.mdx

@@ -1,168 +0,0 @@
----
-title: Email Functionality
-label: Overview
-order: 10
-desc: Payload uses NodeMailer to allow you to send emails smoothly from your app. Set up email functions such as password resets, order confirmations and more.
-keywords: email, overview, config, configuration, documentation, Content Management System, cms, headless, javascript, node, react, express
----
-
-### Introduction
-
-Payload comes ready to send your application's email. Whether you simply need built-in password reset
-email to work or you want customers to get an order confirmation email, you're almost there. Payload makes use of
-[NodeMailer](https://nodemailer.com) for email and won't get in your way for those already familiar.
-
-For email to send from your Payload server, some configuration is required. The settings you provide will be set
-in the `email` property object of your payload init call. Payload will make use of the transport that you have configured for it for things like reset password or verifying new user accounts and email send methods are available to you as well on your payload instance.
-
-### Configuration
-
-**Three ways to set it up**
-
-1. **Default**: When email is not needed, a mock email handler will be created and used when nothing is provided. This is ideal for development environments and can be changed later when ready to [go to production](/docs/production/deployment).
-1. **Recommended**: Set the `transportOptions` and Payload will do the set up for you.
-1. **Advanced**: The `transport` object can be assigned a nodemailer transport object set up in your server scripts and given for Payload to use.
-
-The following options are configurable in the `email` property object as part of the options object when calling payload.init().
-
-| Option                   | Description                                                                                                                                                                                  |
-| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **`fromName`** \*        | The name part of the From field that will be seen on the delivered email                                                                                                                     |
-| **`fromAddress`** \*     | The email address part of the From field that will be used when delivering email                                                                                                             |
-| **`transport`**          | The NodeMailer transport object for when you want to do it yourself, not needed when transportOptions is set                                                                                 |
-| **`transportOptions`**   | An object that configures the transporter that Payload will create. For all the available options see the [NodeMailer documentation](https://nodemailer.com/smtp/) or see the examples below |
-| **`logMockCredentials`** | If set to true and no transport/transportOptions, ethereal credentials will be logged to console on startup                                                                                  |
-
-_\* An asterisk denotes that a property is required._
-
-### Use SMTP
-
-Simple Mail Transfer Protocol, also known as SMTP can be passed in using the `transportOptions` object on the `email` options.
-
-**Example email part using SMTP:**
-
-```ts
-payload.init({
-  email: {
-    transportOptions: {
-      host: process.env.SMTP_HOST,
-      auth: {
-        user: process.env.SMTP_USER,
-        pass: process.env.SMTP_PASS,
-      },
-      port: 587,
-      secure: true, // use TLS
-      tls: {
-        // do not fail on invalid certs
-        rejectUnauthorized: false,
-      },
-    },
-    fromName: "hello",
-    fromAddress: "hello@example.com",
-  },
-  // ...
-});
-```
-
-<Banner type="warning">
-  It is best practice to avoid saving credentials or API keys directly in your code, use [environment variables](/docs/configuration/overview#using-environment-variables-in-your-config).
-</Banner>
-
-### Use an email service
-
-Many third party mail providers are available and offer benefits beyond basic SMTP. As an example your payload init could look this if you wanted to use SendGrid.com though the same approach would work for any other [NodeMailer transports](https://nodemailer.com/transports/) shown here or provided by another third party.
-
-```ts
-import payload from "payload";
-import nodemailerSendgrid from "nodemailer-sendgrid";
-
-const sendGridAPIKey = process.env.SENDGRID_API_KEY;
-
-payload.init({
-  ...(sendGridAPIKey
-    ? {
-        email: {
-          transportOptions: nodemailerSendgrid({
-            apiKey: sendGridAPIKey,
-          }),
-          fromName: "Admin",
-          fromAddress: "admin@example.com",
-        },
-      }
-    : {}),
-});
-```
-
-### Use a custom NodeMailer transport
-
-To take full control of the mail transport you may wish to use `nodemailer.createTransport()` on your server and provide it to Payload init.
-
-```ts
-import payload from "payload";
-import nodemailer from "nodemailer";
-
-const payload = require("payload");
-const nodemailer = require("nodemailer");
-
-const transport = await nodemailer.createTransport({
-  host: process.env.SMTP_HOST,
-  port: 587,
-  auth: {
-    user: process.env.SMTP_USER,
-    pass: process.env.SMTP_PASS,
-  },
-});
-
-payload.init({
-  email: {
-    fromName: "Admin",
-    fromAddress: "admin@example.com",
-    transport,
-  },
-  // ...
-});
-```
-
-### Sending Mail
-
-With a working transport you can call it anywhere you have access to payload by calling `payload.sendEmail(message)`. The `message` will contain the `to`, `subject` and `email` or `text` for the email being sent. To see all available message configuration options see [NodeMailer](https://nodemailer.com/message).
-
-### Mock transport
-
-By default, Payload uses a mock implementation that only sends mail to the [ethereal](https://ethereal.email) capture service that will never reach a user's inbox. While in development you may wish to make use of the captured messages which is why the payload output during server output helpfully logs this out on the server console.
-
-To see ethereal credentials, add `logMockCredentials: true` to the email options. This will cause them to be logged to console on startup.
-
-```ts
-payload.init({
-  email: {
-    fromName: "Admin",
-    fromAddress: "admin@example.com",
-    logMockCredentials: true, // Optional
-  },
-  // ...
-});
-```
-
-**Console output when starting payload with a mock email instance and logMockCredentials: true**
-
-```
-[06:37:21] INFO  (payload): Starting Payload...
-[06:37:22] INFO  (payload): Payload Demo Initialized
-[06:37:22] INFO  (payload): listening on 3000...
-[06:37:22] INFO  (payload): Connected to MongoDB server successfully!
-[06:37:23] INFO  (payload): E-mail configured with mock configuration
-[06:37:23] INFO  (payload): Log into mock email provider at https://ethereal.email
-[06:37:23] INFO  (payload): Mock email account username: hhav5jw7doo4euev@ethereal.email
-[06:37:23] INFO  (payload): Mock email account password: VNdGcvDZeyEhtuPBqf
-```
-
-The mock email handler is used when payload is started with neither `transport` or `transportOptions` to know how to deliver email.
-
-<Banner type="warning">
-  The randomly generated email account username and password will be different each time the Payload server starts.
-</Banner>
-
-### Using multiple mail providers
-
-Payload supports the use of a single transporter of email, but there is nothing stopping you from having more. Consider a use case where sending bulk email is handled differently than transactional email and could be done using a [hook](/docs/hooks/overview).

package/docs/fields/array.mdx

@@ -1,109 +0,0 @@
----
-title: Array Field
-label: Array
-order: 20
-desc: Array fields are intended for sets of repeating fields, that you define. Learn how to use array fields, see examples and options.
-keywords: array, fields, config, configuration, documentation, Content Management System, cms, headless, javascript, node, react, express
----
-
-<Banner>
-  The Array field type is used when you need to have a set of "repeating"
-  fields. It stores an array of objects containing the fields that you define.
-  Its uses can be simple or highly complex.
-</Banner>
-
-<LightDarkImage
-  srcLight="https://payloadcms.com/images/docs/fields/array.png"
-  srcDark="https://payloadcms.com/images/docs/fields/array-dark.png"
-  alt="Array field with two Rows in Payload admin panel"
-  caption="Admin panel screenshot of an Array field with two Rows"
-/>
-
-**Example uses:**
-
-- A "slider" with an image ([upload field](/docs/fields/upload)) and a caption ([text field](/docs/fields/text))
-- Navigational structures where editors can specify nav items containing pages ([relationship field](/docs/fields/relationship)), an "open in new tab" [checkbox field](/docs/fields/checkbox)
-- Event agenda "timeslots" where you need to specify start & end time ([date field](/docs/fields/date)), label ([text field](/docs/fields/text)), and Learn More page [relationship](/docs/fields/relationship)
-
-### Config
-
-| Option              | Description                                                                                                                                                                                                                                                                        |
-| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **`name`** \*       | To be used as the property name when stored and retrieved from the database. [More](/docs/fields/overview#field-names)                                                                                                                                                             |
-| **`label`**         | Text used as the heading in the Admin panel or an object with keys for each language. Auto-generated from name if not defined.                                                                                                                                                     |
-| **`fields`** \*     | Array of field types to correspond to each row of the Array.                                                                                                                                                  |
-| **`validate`**      | Provide a custom validation function that will be executed on both the Admin panel and the backend. [More](/docs/fields/overview#validation)   
-| **`minRows`**       | A number for the fewest allowed items during validation when a value is present.                                                                                           |
-| **`maxRows`**       | A number for the most allowed items during validation when a value is present.                                                                                                                                                                                                    |
-| **`saveToJWT`**     | If this field is top-level and nested in a config supporting [Authentication](/docs/authentication/config), include its data in the user JWT.                                                                                                                                      |
-| **`hooks`**         | Provide field-based hooks to control logic for this field. [More](/docs/fields/overview#field-level-hooks)                                                                                                                                                                         |
-| **`access`**        | Provide field-based access control to denote what users can see and do with this field's data. [More](/docs/fields/overview#field-level-access-control)                                                                                                                            |
-| **`hidden`**        | Restrict this field's visibility from all APIs entirely. Will still be saved to the database, but will not appear in any API or the Admin panel.                                                                                                                                   |
-| **`defaultValue`**  | Provide an array of row data to be used for this field's default value. [More](/docs/fields/overview#default-values)                                                                                                                                                               |
-| **`localized`**     | Enable localization for this field. Requires [localization to be enabled](/docs/configuration/localization) in the Base config. If enabled, a separate, localized set of all data within this Array will be kept, so there is no need to specify each nested field as `localized`. |
-| **`required`**      | Require this field to have a value.                                                                                                                                                                                                                                                |
-| **`labels`**        | Customize the row labels appearing in the Admin dashboard.                                                                                                                                                                                                                         |
-| **`admin`**         | Admin-specific configuration. See below for [more detail](#admin-config).                                                                                                                                                                                                          |
-| **`custom`**        | Extension point for adding custom data (e.g. for plugins)                                                                                                                                                                                                                          |
-| **`interfaceName`** | Create a top level, reusable [Typescript interface](/docs/typescript/generating-types#custom-field-interfaces) & [GraphQL type](/docs/graphql/graphql-schema#custom-field-schemas).                                                                                                |
-
-_\* An asterisk denotes that a property is required._
-
-### Admin Config
-
-In addition to the default [field admin config](/docs/fields/overview#admin-config), you can adjust the following properties:
-
-| Option                    | Description                                                                                                          |
-| ------------------------- | -------------------------------------------------------------------------------------------------------------------- |
-| **`initCollapsed`**       | Set the initial collapsed state                                                                                      |
-| **`components.RowLabel`** | Function or React component to be rendered as the label on the array row. Receives `({ data, index, path })` as args |
-
-### Example
-
-`collections/ExampleCollection.ts`
-
-```ts
-import { CollectionConfig } from "payload/types";
-
-export const ExampleCollection: CollectionConfig = {
-  slug: "example-collection",
-  fields: [
-    {
-      name: "slider", // required
-      type: "array", // required
-      label: "Image Slider",
-      minRows: 2,
-      maxRows: 10,
-      interfaceName: "CardSlider", // optional
-      labels: {
-        singular: "Slide",
-        plural: "Slides",
-      },
-      fields: [
-        // required
-        {
-          name: "title",
-          type: "text",
-        },
-        {
-          name: "image",
-          type: "upload",
-          relationTo: "media",
-          required: true,
-        },
-        {
-          name: "caption",
-          type: "text",
-        },
-      ],
-      admin: {
-        components: {
-          RowLabel: ({ data, index }) => {
-            return data?.title || `Slide ${String(index).padStart(2, "0")}`;
-          },
-        },
-      },
-    },
-  ],
-};
-```