Кастомні поля Payload CMS — розробка, валідація, React-компоненти

Стандартні поля Payload CMS покривають 80% задач. Але коли клієнту потрібен вибір кольору з палітри бренду — не текстом, а візуально — доводиться писати кастомний компонент. Офіційна документація Payload CMS по кастомним полям (Custom Fields) дозволяє додати будь-який UI в адмінці, зберігши строгу серверну валідацію. Ми часто стикаємося з такими запитами: селектор кольору, кастомний редактор JSON, поле з автодоповненням із зовнішнього API. Вбудовані типи не гнучкі, тому ми розробляємо кастомні рішення під ключ за 2-3 дні. Наш досвід — понад 10 років у React, TypeScript, Payload CMS. Виконали більше 50 проєктів з кастомними полями. Середня економія часу редакторів після впровадження — 70%. Зв'яжіться з нами для обговорення вашого кейсу.

Чому стандартних полів Payload CMS недостатньо?

Вбудовані типи (text, number, select) хороші для типових задач. Але як тільки потрібен нестандартний UI — візуальний вибір кольору, кастомний редактор з прев'ю, динамічне завантаження даних — доводиться розширювати функціонал. Альтернатива — написати плагін, але частіше простіше створити кастомне поле. Воно дає повний контроль над відображенням та валідацією, а код залишається в рамках однієї колекції. Порівняйте: налаштування select з умовною видимістю займає 15 хвилин, а кастомний компонент з автодоповненням з API — близько 4 годин. Але результат на порядок зручніший для редактора. Наприклад, в одному з проєктів ми замінили 10 стандартних полів одним кастомним блоком — швидкість заповнення зросла в 3 рази.

Як створити кастомне поле з валідацією?

Розглянемо поле для введення номера телефону з маскою +7. Проста валідація регулярним виразом — але додамо кастомний компонент для відображення маски. Валідація виконується і на клієнті (в адмінці), і на сервері при збереженні. Це типова задача, яку ми вирішуємо регулярно.

{
  name: 'phone',
  type: 'text',
  validate: (value) => {
    if (!value) return true
    const phoneRegex = /^\+7\d{10}$/
    if (!phoneRegex.test(value)) {
      return 'Формат: +7XXXXXXXXXX'
    }
    return true
  },
}

Для більш складних сценаріїв, наприклад, умовна видимість поля, використовуємо admin.condition. Це знижує навантаження на користувача: якщо чекбокс неактивний, поле ховається.

Як підключити кастомний UI-компонент? — кастомні поля payload

Для нестандартного відображення в адмінці створюємо React-компонент. Дані зберігаються як звичайно, а UI змінюється. Приклад — ColorPicker:

'use client'
import { useField } from 'payload/components/forms'

const ColorPickerField = ({ path }: { path: string }) => {
  const { value, setValue } = useField<string>({ path })
  const colors = ['#FF5733', '#33FF57', '#3357FF', '#FF33A8', '#33A8FF']

  return (
    <div className="field-type">
      <label className="field-label">Колір</label>
      <div style={{ display: 'flex', gap: 8 }}>
        {colors.map(color => (
          <div
            key={color}
            onClick={() => setValue(color)}
            style={{
              width: 32,
              height: 32,
              borderRadius: '50%',
              background: color,
              cursor: 'pointer',
              border: value === color ? '3px solid #000' : '2px solid transparent'
            }}
          />
        ))}
      </div>
      <input
        type="text"
        value={value || ''}
        onChange={e => setValue(e.target.value)}
        placeholder="#000000"
        style={{ marginTop: 8 }}
      />
    </div>
  )
}

export default ColorPickerField

Підключення в колекції:

{ name: 'brandColor', type: 'text', admin: { components: { Field: '/fields/ColorPicker/index#ColorPickerField', }, }, } 

Точно так само можна підключати кастомні редактори, інтеграції з Figma або генератори QR-кодів. Наші інженери беруть на себе повну розробку компонента — від прототипу до тестування. Отримайте консультацію по вашому проєкту — напишіть нам.

Чому Blocks — найкращий вибір для гнучких сторінок?

Blocks — це конструктор сторінок, де редактор сам обирає тип блоку (текст, зображення, CTA). На відміну від Arrays або Groups, Blocks підтримують різні набори полів у кожному блоці. Порівняємо:

Приклад конфігурації Blocks:

const TextBlock: Block = {
  slug: 'textBlock',
  fields: [
    {
      name: 'content',
      type: 'richText',
    },
    {
      name: 'columns',
      type: 'select',
      options: [
        {
          label: '1 колонка',
          value: '1',
        },
        {
          label: '2 колонки',
          value: '2',
        },
      ],
      defaultValue: '1',
    },
  ],
}

const ImageBlock: Block = {
  slug: 'imageBlock',
  fields: [
    {
      name: 'image',
      type: 'upload',
      relationTo: 'media',
      required: true,
    },
    {
      name: 'caption',
      type: 'text',
    },
    {
      name: 'fullWidth',
      type: 'checkbox',
      defaultValue: false,
    },
  ],
}

Використання Blocks скорочує час розробки сторінок у 2-3 рази порівняно з Array. Редактор сам збирає layout, а ми гарантуємо коректний рендеринг на всіх пристроях. Зв'яжіться з нами для обговорення ваших задач.

Що таке віртуальні поля і для чого вони потрібні?

Іноді потрібно обчислити значення на льоту, не зберігаючи його. Використовуємо хуки afterRead. Такі поля корисні для відображення складених даних, наприклад, повного імені з імені та прізвища. Вони не впливають на продуктивність, оскільки обчислюються тільки при читанні. Приклад — віртуальне поле fullName:

{ name: 'fullName', type: 'text', hooks: { afterRead: [({ data }) => `${data.firstName} ${data.lastName}`], }, } 

Такі поля економлять місце в базі та спрощують API.

Що входить до роботи з розробки кастомних полів?

Ми надаємо повний цикл: від аналізу вимог до деплою та документації. У таблиці — ключові етапи.

Терміни орієнтовні. Для складних полів (інтеграція із зовнішнім API) може знадобитися більше часу. Ми оцінимо ваш проєкт — зв'яжіться з нами.

Гарантуємо якість реалізації: всі поля проходять code review та unit-тестування. Отримайте консультацію по вашому проєкту — напишіть нам.