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.

0 0 0 TypeScript
Normal View History Raw
doc: stubs out all fields so docs are not broken
2020-12-30 13:47:28 -05:00
---
title: Checkbox Field
label: Checkbox
docs: orders fields
2020-12-31 09:58:08 -05:00
order: 40
feat: adds meta descriptions to docs
2021-02-03 16:55:22 -05:00
desc: Checkbox field types allow the developer to save a boolean value in the database. Learn how to use Checkbox fields, see examples and options.
docs: removes express
2024-05-13 10:29:59 -04:00
keywords: checkbox, 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
---
feat(next): root admin (#7276)
2024-07-23 13:44:44 -04:00
The Checkbox Field saves a boolean in the database.
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: adds images to each field page (#3137)
2023-08-08 15:00:21 +01:00
<LightDarkImage
srcLight="https://payloadcms.com/images/docs/fields/checkbox.png"
srcDark="https://payloadcms.com/images/docs/fields/checkbox-dark.png"
docs: misc improvements (#7107)
2024-07-11 09:54:21 -04:00
alt="Checkbox field with text field in Payload Admin Panel"
docs: improves configuration docs (#7090)
2024-07-09 18:10:04 -04:00
caption="Admin Panel screenshot of Checkbox field with Text field below"
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 Checkbox Field, set the `type` to `checkbox` in your [Field Config](./overview):
```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 MyCheckboxField: Field = {
// ...
type: 'checkbox', // highlight-line
}
```
## Config Options
docs: orders fields
2020-12-31 09:58:08 -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: 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). |
| **`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
| **`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, will default to false if field is also `required`. [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. [More details](./overview#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) |
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
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: orders fields
2020-12-31 09:58:08 -05:00
docs: new and improve lexical docs, hoist up all headings (#6639)
2024-06-05 17:08:15 -04:00
## Example
docs: orders fields
2020-12-31 09:58:08 -05:00
docs: cleanup to individual field docs (#7202)
2024-07-22 23:46:06 -04:00
Here is an example of a Checkbox Field in a Collection:
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: orders fields
2020-12-31 09:58:08 -05:00
slug: 'example-collection',
fields: [
{
name: 'enableCoolStuff', // required
type: 'checkbox', // required
label: 'Click me to see fanciness',
defaultValue: false,
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: orders fields
2020-12-31 09:58:08 -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 { CheckboxField } from '@payloadcms/ui'
import type { CheckboxFieldServerComponent } from 'payload'
export const CustomCheckboxFieldServer: CheckboxFieldServerComponent = ({
clientField,
path,
schemaPath,
permissions,
}) => {
return (
<CheckboxField
field={clientField}
path={path}
schemaPath={schemaPath}
permissions={permissions}
/>
)
}
```
#### Client Component
```tsx
'use client'
import React from 'react'
import { CheckboxField } from '@payloadcms/ui'
import type { CheckboxFieldClientComponent } from 'payload'
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
export const CustomCheckboxFieldClient: CheckboxFieldClientComponent = (
props,
) => {
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
return <CheckboxField {...props} />
}
```
### Label
#### Server Component
```tsx
import React from 'react'
import { FieldLabel } from '@payloadcms/ui'
import type { CheckboxFieldLabelServerComponent } from 'payload'
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
export const CustomCheckboxFieldLabelServer: CheckboxFieldLabelServerComponent =
({ clientField, path }) => {
return (
<FieldLabel
label={clientField?.label || clientField?.name}
path={path}
required={clientField?.required}
/>
)
}
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 { FieldLabel } from '@payloadcms/ui'
import type { CheckboxFieldLabelClientComponent } from 'payload'
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
export const CustomCheckboxFieldLabelClient: CheckboxFieldLabelClientComponent =
({ label, path, required }) => {
return (
<FieldLabel
label={field?.label || field?.name}
path={path}
required={field?.required}
/>
)
}
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
```
Reference in New Issue Copy Permalink