MORPH
SIGN IN SIGN UP
payloadcms / payload UNCLAIMED

Payload is the open-source, fullstack Next.js framework, giving you instant backend superpowers. Get a full TypeScript backend and admin panel instantly. Use Payload as a headless CMS or for building powerful applications.

41523 0 16 TypeScript
Normal View History Raw
doc: stubs out all fields so docs are not broken
2020-12-30 13:47:28 -05:00
---
title: Code Field
label: Code
docs: orders fields
2020-12-31 09:58:08 -05:00
order: 50
feat: adds meta descriptions to docs
2021-02-03 16:55:22 -05:00
desc: The Code field type will store any string in the Database. Learn how to use Code fields, see examples and options.
docs: removes express
2024-05-13 10:29:59 -04:00
keywords: code, fields, config, configuration, documentation, Content Management System, cms, headless, javascript, node, react, nextjs
doc: stubs out all fields so docs are not broken
2020-12-30 13:47:28 -05:00
---
docs: cleanup to individual field docs (#7202)
2024-07-22 23:46:06 -04:00
The Code Field saves a string in the database, but provides the [Admin Panel](../admin/overview) with a code editor styled interface.
docs: field types
2020-12-31 11:19:59 -05:00
docs: adds images to each field page (#3137)
2023-08-08 15:00:21 +01:00
<LightDarkImage
srcLight="https://payloadcms.com/images/docs/fields/code.png"
srcDark="https://payloadcms.com/images/docs/fields/code-dark.png"
docs: misc improvements (#7107)
2024-07-11 09:54:21 -04:00
alt="Shows a Code field in the Payload Admin Panel"
docs: cleanup to individual field docs (#7202)
2024-07-22 23:46:06 -04:00
caption="This field is using the `monaco-react` editor syntax highlighting."
docs: adds images to each field page (#3137)
2023-08-08 15:00:21 +01:00
/>
docs: cleanup to individual field docs (#7202)
2024-07-22 23:46:06 -04:00
To add a Code Field, set the `type` to `code` in your [Field Config](./overview):
docs: field types
2020-12-31 11:19:59 -05:00
docs: cleanup to individual field docs (#7202)
2024-07-22 23:46:06 -04:00
```ts
docs: corrects old imports (#8769) 1 `import type { Field } from 'payload/types'` to `import type { Field } from 'payload'` 2 `import { buildConfig } from 'payload/config'` to `import { buildConfig } from 'payload'` 3 ``` import { SelectInput, useField } from 'payload/components/forms'; import { useAuth } from 'payload/components/utilities'; ``` to `import { SelectInput, useAuth, useField } from '@payloadcms/ui'` 4 uses `import type` for `import type { CollectionConfig } from 'payload'`
2024-10-18 10:47:47 +03:00
import type { Field } from 'payload'
docs: cleanup to individual field docs (#7202)
2024-07-22 23:46:06 -04:00
export const MyBlocksField: Field = {
// ...
type: 'code', // highlight-line
}
```
## Config Options
docs: field types
2020-12-31 11:19:59 -05:00
docs: virtual fields linking with relationship fields (#12145) Adds docs for these changes https://github.com/payloadcms/payload/pull/11805
2025-04-18 21:56:19 +03:00
| Option | Description |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
docs: performance (#13068) Payload is designed with performance in mind, but its customizability means that there are many ways to configure your app that can impact performance. While Payload provides several features and best practices to help you optimize your app's specific performance needs, these are not currently well surfaced and can be obscure. Now: - A high-level performance doc now exists at `/docs/performance` - There's a new section on performance within the `/docs/queries` doc - There's a new section on performance within the `/docs/hooks` doc - There's a new section on performance within the `/docs/custom-components` doc This PR also: - Restructures and elaborates on the `/docs/queries/pagination` docs - Adds a new `/docs/database/indexing` doc - More --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1210743577153856
2025-07-14 23:55:16 -04:00
| **`name`** \* | To be used as the property name when stored and retrieved from the database. [More details](/docs/fields/overview#field-names). |
docs: virtual fields linking with relationship fields (#12145) Adds docs for these changes https://github.com/payloadcms/payload/pull/11805
2025-04-18 21:56:19 +03:00
| **`label`** | Text used as a field label in the Admin Panel or an object with keys for each language. |
docs: clarify unique field index behavior and add warnings for array/blocks nesting (#15969) Fixes #12836 - updates description for unique in each field config - adds a Unique Fields section explaining the collection-wide index behavior - adds a warning banner after the config options table pointing to the new indexes section --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1213860518113240 --------- Co-authored-by: Patrik Kozak <35232443+PatrikKozak@users.noreply.github.com>
2026-03-31 10:43:01 -04:00
| **`unique`** | Enforce that each entry in the Collection has a unique value for this field. This creates a database-level unique index on the field's path. [More details](/docs/database/indexes#unique-fields). |
docs: performance (#13068) Payload is designed with performance in mind, but its customizability means that there are many ways to configure your app that can impact performance. While Payload provides several features and best practices to help you optimize your app's specific performance needs, these are not currently well surfaced and can be obscure. Now: - A high-level performance doc now exists at `/docs/performance` - There's a new section on performance within the `/docs/queries` doc - There's a new section on performance within the `/docs/hooks` doc - There's a new section on performance within the `/docs/custom-components` doc This PR also: - Restructures and elaborates on the `/docs/queries/pagination` docs - Adds a new `/docs/database/indexing` doc - More --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1210743577153856
2025-07-14 23:55:16 -04:00
| **`index`** | Build an [index](../database/indexes) for this field to produce faster queries. Set this field to `true` if your users will perform queries on this field's data often. |
docs: virtual fields linking with relationship fields (#12145) Adds docs for these changes https://github.com/payloadcms/payload/pull/11805
2025-04-18 21:56:19 +03:00
| **`minLength`** | Used by the default validation function to ensure values are of a minimum character length. |
| **`maxLength`** | Used by the default validation function to ensure values are of a maximum character length. |
docs: performance (#13068) Payload is designed with performance in mind, but its customizability means that there are many ways to configure your app that can impact performance. While Payload provides several features and best practices to help you optimize your app's specific performance needs, these are not currently well surfaced and can be obscure. Now: - A high-level performance doc now exists at `/docs/performance` - There's a new section on performance within the `/docs/queries` doc - There's a new section on performance within the `/docs/hooks` doc - There's a new section on performance within the `/docs/custom-components` doc This PR also: - Restructures and elaborates on the `/docs/queries/pagination` docs - Adds a new `/docs/database/indexing` doc - More --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1210743577153856
2025-07-14 23:55:16 -04:00
| **`validate`** | Provide a custom validation function that will be executed on both the Admin Panel and the backend. [More details](/docs/fields/overview#validation). |
docs: virtual fields linking with relationship fields (#12145) Adds docs for these changes https://github.com/payloadcms/payload/pull/11805
2025-04-18 21:56:19 +03:00
| **`saveToJWT`** | If this field is top-level and nested in a config supporting [Authentication](/docs/authentication/overview), include its data in the user JWT. |
| **`hooks`** | Provide Field Hooks to control logic for this field. [More details](../hooks/fields). |
| **`access`** | Provide Field Access Control to denote what users can see and do with this field's data. [More details](../access-control/fields). |
| **`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. |
docs: performance (#13068) Payload is designed with performance in mind, but its customizability means that there are many ways to configure your app that can impact performance. While Payload provides several features and best practices to help you optimize your app's specific performance needs, these are not currently well surfaced and can be obscure. Now: - A high-level performance doc now exists at `/docs/performance` - There's a new section on performance within the `/docs/queries` doc - There's a new section on performance within the `/docs/hooks` doc - There's a new section on performance within the `/docs/custom-components` doc This PR also: - Restructures and elaborates on the `/docs/queries/pagination` docs - Adds a new `/docs/database/indexing` doc - More --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1210743577153856
2025-07-14 23:55:16 -04:00
| **`defaultValue`** | Provide data to be used for this field's default value. [More details](/docs/fields/overview#default-values). |
docs: virtual fields linking with relationship fields (#12145) Adds docs for these changes https://github.com/payloadcms/payload/pull/11805
2025-04-18 21:56:19 +03:00
| **`localized`** | Enable localization for this field. Requires [localization to be enabled](/docs/configuration/localization) in the Base config. |
| **`required`** | Require this field to have a value. |
| **`admin`** | Admin-specific configuration. See below for [more detail](#admin-options). |
| **`custom`** | Extension point for adding custom data (e.g. for plugins) |
| **`typescriptSchema`** | Override field type generation with providing a JSON schema |
| **`virtual`** | Provide `true` to disable field in the database, or provide a string path to [link the field with a relationship](/docs/fields/relationship#linking-virtual-fields-with-relationships). See [Virtual Fields](https://payloadcms.com/blog/learn-how-virtual-fields-can-help-solve-common-cms-challenges) |
fix: reverts ESLint syntax changes to mdx files
2021-02-04 11:36:09 -05:00
chore: bump prettier, re-enable prettier for docs (#11695) ## Introducing Prettier for docs Prettier [was originally disabled for our docs as it didn't support MDX 2.0](https://github.com/payloadcms/payload/commit/1fa636417f7c5cc79b7934e88e2c1c2bf36dceec), outputting invalid MDX syntax. This has since been fixed - prettier now supports MDX 2.0. ## Reducing print width This also reduces the print width for the docs folder from 100 to 70. Our docs code field are very narrow - this should help make code more readable. **Before** ![CleanShot 2025-03-13 at 19 58 11@2x](https://github.com/user-attachments/assets/0ae9e27b-cddf-44e5-a978-c8e24e99a314) **After** ![CleanShot 2025-03-13 at 19 59 19@2x](https://github.com/user-attachments/assets/0e424f99-002c-4adc-9b37-edaeef239b0d) **Before** ![CleanShot 2025-03-13 at 20 00 05@2x](https://github.com/user-attachments/assets/614e51b3-aa0d-45e7-98f4-fcdb1a778bcf) **After** ![CleanShot 2025-03-13 at 20 00 16@2x](https://github.com/user-attachments/assets/be46988a-2cba-43fc-a8cd-fd3c781da930)
2025-03-14 11:13:08 -06:00
_\* An asterisk denotes that a property is required._
docs: field types
2020-12-31 11:19:59 -05:00
docs: cleanup to individual field docs (#7202)
2024-07-22 23:46:06 -04:00
## Admin Options
docs: fixes misc grammar and spelling errors (#10996) Fixed various spelling/grammatical errors found when reading the docs.
2025-02-11 13:37:23 -05:00
To customize the appearance and behavior of the Code Field in the [Admin Panel](../admin/overview), you can use the `admin` option:
docs: cleanup to individual field docs (#7202)
2024-07-22 23:46:06 -04:00
```ts
docs: corrects old imports (#8769) 1 `import type { Field } from 'payload/types'` to `import type { Field } from 'payload'` 2 `import { buildConfig } from 'payload/config'` to `import { buildConfig } from 'payload'` 3 ``` import { SelectInput, useField } from 'payload/components/forms'; import { useAuth } from 'payload/components/utilities'; ``` to `import { SelectInput, useAuth, useField } from '@payloadcms/ui'` 4 uses `import type` for `import type { CollectionConfig } from 'payload'`
2024-10-18 10:47:47 +03:00
import type { Field } from 'payload'
docs: cleanup to individual field docs (#7202)
2024-07-22 23:46:06 -04:00
export const MyCodeField: Field = {
// ...
chore: bump prettier, re-enable prettier for docs (#11695) ## Introducing Prettier for docs Prettier [was originally disabled for our docs as it didn't support MDX 2.0](https://github.com/payloadcms/payload/commit/1fa636417f7c5cc79b7934e88e2c1c2bf36dceec), outputting invalid MDX syntax. This has since been fixed - prettier now supports MDX 2.0. ## Reducing print width This also reduces the print width for the docs folder from 100 to 70. Our docs code field are very narrow - this should help make code more readable. **Before** ![CleanShot 2025-03-13 at 19 58 11@2x](https://github.com/user-attachments/assets/0ae9e27b-cddf-44e5-a978-c8e24e99a314) **After** ![CleanShot 2025-03-13 at 19 59 19@2x](https://github.com/user-attachments/assets/0e424f99-002c-4adc-9b37-edaeef239b0d) **Before** ![CleanShot 2025-03-13 at 20 00 05@2x](https://github.com/user-attachments/assets/614e51b3-aa0d-45e7-98f4-fcdb1a778bcf) **After** ![CleanShot 2025-03-13 at 20 00 16@2x](https://github.com/user-attachments/assets/be46988a-2cba-43fc-a8cd-fd3c781da930)
2025-03-14 11:13:08 -06:00
admin: {
// highlight-line
docs: cleanup to individual field docs (#7202)
2024-07-22 23:46:06 -04:00
// ...
},
}
```
docs: field types
2020-12-31 11:19:59 -05:00
feat: select field filter options (#12487) It is a common pattern to dynamically show and validate a select field's options based on various criteria such as the current user or underlying document. Some examples of this might include: - Restricting options based on a user's role, e.g. admin-only options - Displaying different options based on the value of another field, e.g. a city/state selector While this is already possible to do with a custom `validate` function, the user can still view and select the forbidden option...unless you _also_ wired up a custom component. Now, you can define `filterOptions` on select fields. This behaves similarly to the existing `filterOptions` property on relationship and upload fields, except the return value of this function is simply an array of options, not a query constraint. The result of this function will determine what is shown to the user and what is validated on the server. Here's an example: ```ts { name: 'select', type: 'select', options: [ { label: 'One', value: 'one', }, { label: 'Two', value: 'two', }, { label: 'Three', value: 'three', }, ], filterOptions: ({ options, data }) => data.disallowOption1 ? options.filter( (option) => (typeof option === 'string' ? options : option.value) !== 'one', ) : options, } ```
2025-05-22 15:54:12 -04:00
The Code Field inherits all of the default admin options from the base [Field Admin Config](./overview#admin-options), plus the following additional options:
docs: field types
2020-12-31 11:19:59 -05:00
chore: moves editorProps into admin property for code and json field types
2023-01-04 08:41:59 -05:00
| Option | Description |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **`language`** | This property can be set to any language listed [here](https://github.com/microsoft/monaco-editor/tree/main/src/basic-languages). |
fix: checks locale is valid for monaco code editor (#2144)
2023-02-20 18:52:04 +00:00
| **`editorOptions`** | Options that can be passed to the monaco editor, [view the full list](https://microsoft.github.io/monaco-editor/typedoc/interfaces/editor.IDiffEditorConstructionOptions.html). |
docs: field types
2020-12-31 11:19:59 -05:00
docs: new and improve lexical docs, hoist up all headings (#6639)
2024-06-05 17:08:15 -04:00
## Example
docs: field types
2020-12-31 11:19:59 -05:00
docs: update examples with ts types
2022-08-23 11:43:24 -04:00
`collections/ExampleCollection.ts
chore: formatting and linting (#3261) * chore: lint packages/payload * chore: lint packages/db-postgres * chore: lint packages/db-mongodb * chore: update eslintrc exclusion rules * chore: update eslintrc exclusion rules * chore: lint misc files * chore: run prettier through packages * chore: run eslint on payload again * chore: prettier misc files * chore: prettier docs
2023-09-01 17:39:44 +02:00
docs: update examples with ts types
2022-08-23 11:43:24 -04:00
```ts
docs: corrects old imports (#8769) 1 `import type { Field } from 'payload/types'` to `import type { Field } from 'payload'` 2 `import { buildConfig } from 'payload/config'` to `import { buildConfig } from 'payload'` 3 ``` import { SelectInput, useField } from 'payload/components/forms'; import { useAuth } from 'payload/components/utilities'; ``` to `import { SelectInput, useAuth, useField } from '@payloadcms/ui'` 4 uses `import type` for `import type { CollectionConfig } from 'payload'`
2024-10-18 10:47:47 +03:00
import type { CollectionConfig } from 'payload'
docs: update examples with ts types
2022-08-23 11:43:24 -04:00
chore: misc documentation updates (#2589) * chore: ensures example configs are being exported when necessary * chore: adds note regarding updating of hidden fields --------- Co-authored-by: Jessica Boezwinkle <jessica@trbl.design>
2023-05-01 16:28:13 -04:00
export const ExampleCollection: CollectionConfig = {
docs: field types
2020-12-31 11:19:59 -05:00
slug: 'example-collection',
fields: [
{
name: 'trackingCode', // required
type: 'code', // required
required: true,
admin: {
docs: updates code and json field types to reflect internal switch to monaco-react editor
2023-01-03 15:01:04 -05:00
language: 'javascript',
docs: field types
2020-12-31 11:19:59 -05:00
},
},
],
docs: update examples with ts types
2022-08-23 11:43:24 -04:00
}
docs: field types
2020-12-31 11:19:59 -05:00
```
docs: adds examples of typed custom field components (#10741) Although the "customizing fields" doc provides a big picture overview of how to create custom field components, it is not explicit enough for developers to know exactly where to start. For example, it can be challenging to import the correct types when building these components, and the natural place to go looking for this information is on the fields docs themselves. Now, each field doc has its own dedicated "custom components" section which provides concrete examples for fields and field labels in both server and client component format, with more examples to come over time such as using inputs directly, etc. In the same vein, the "customizing fields" doc itself should probably be moved to the fields overview section so it remains as intuitive as possible when searching for this information.
2025-01-22 23:07:09 -05:00
## Custom Components
### Field
#### Server Component
```tsx
import type React from 'react'
import { CodeField } from '@payloadcms/ui'
import type { CodeFieldServerComponent } from 'payload'
export const CustomCodeFieldServer: CodeFieldServerComponent = ({
clientField,
path,
schemaPath,
permissions,
}) => {
return (
chore: bump prettier, re-enable prettier for docs (#11695) ## Introducing Prettier for docs Prettier [was originally disabled for our docs as it didn't support MDX 2.0](https://github.com/payloadcms/payload/commit/1fa636417f7c5cc79b7934e88e2c1c2bf36dceec), outputting invalid MDX syntax. This has since been fixed - prettier now supports MDX 2.0. ## Reducing print width This also reduces the print width for the docs folder from 100 to 70. Our docs code field are very narrow - this should help make code more readable. **Before** ![CleanShot 2025-03-13 at 19 58 11@2x](https://github.com/user-attachments/assets/0ae9e27b-cddf-44e5-a978-c8e24e99a314) **After** ![CleanShot 2025-03-13 at 19 59 19@2x](https://github.com/user-attachments/assets/0e424f99-002c-4adc-9b37-edaeef239b0d) **Before** ![CleanShot 2025-03-13 at 20 00 05@2x](https://github.com/user-attachments/assets/614e51b3-aa0d-45e7-98f4-fcdb1a778bcf) **After** ![CleanShot 2025-03-13 at 20 00 16@2x](https://github.com/user-attachments/assets/be46988a-2cba-43fc-a8cd-fd3c781da930)
2025-03-14 11:13:08 -06:00
<CodeField
field={clientField}
path={path}
schemaPath={schemaPath}
permissions={permissions}
/>
docs: adds examples of typed custom field components (#10741) Although the "customizing fields" doc provides a big picture overview of how to create custom field components, it is not explicit enough for developers to know exactly where to start. For example, it can be challenging to import the correct types when building these components, and the natural place to go looking for this information is on the fields docs themselves. Now, each field doc has its own dedicated "custom components" section which provides concrete examples for fields and field labels in both server and client component format, with more examples to come over time such as using inputs directly, etc. In the same vein, the "customizing fields" doc itself should probably be moved to the fields overview section so it remains as intuitive as possible when searching for this information.
2025-01-22 23:07:09 -05:00
)
}
```
#### Client Component
```tsx
'use client'
import React from 'react'
import { CodeField } from '@payloadcms/ui'
import type { CodeFieldClientComponent } from 'payload'
export const CustomCodeFieldClient: CodeFieldClientComponent = (props) => {
return <CodeField {...props} />
}
```
### Label
#### Server Component
```tsx
import React from 'react'
import { FieldLabel } from '@payloadcms/ui'
import type { CodeFieldLabelServerComponent } from 'payload'
export const CustomCodeFieldLabelServer: CodeFieldLabelServerComponent = ({
clientField,
path,
}) => {
return (
<FieldLabel
label={clientField?.label || clientField?.name}
path={path}
required={clientField?.required}
/>
)
}
```
#### Client Component
```tsx
'use client'
import React from 'react'
import { FieldLabel } from '@payloadcms/ui'
import type { CodeFieldLabelClientComponent } from 'payload'
export const CustomCodeFieldLabelClient: CodeFieldLabelClientComponent = ({
field,
path,
}) => {
return (
<FieldLabel
label={field?.label || field?.name}
path={path}
required={field?.required}
/>
)
}
```
Reference in New Issue Copy Permalink