Ми реалізували кастомні хуки для Payload CMS на 20+ проектах: від інтернет-магазинів до корпоративних порталів. Типові валідатори не справляються з перевіркою залишків через зовнішнє API, генерацією унікальних номерів замовлень або відправкою сповіщень у Telegram.
В одному проекті потрібно було розрахувати знижку на основі історії покупок — це вимагало складного beforeChange хука зі зверненням до окремої таблиці. Без кастомного хука довелося б змінювати ядро CMS, що неприпустимо. Результат: знижка розраховується за 200 мс замість 5 секунд вручну.
Кастомні хуки вбудовуються в життєвий цикл документа без модифікації вихідного коду Payload. За 5+ років ми написали десятки таких рішень, і кожне вимагало глибокого розуміння lifecycle колекцій. В середньому один хук економить 3–4 години ручної роботи на тиждень, що на 80% скорочує час на валідацію. Кожен хук строго типізований на TypeScript і покритий тестами.
Як кастомні хуки вирішують завдання бізнес-логіки?
Хуки Payload працюють на різних етапах: beforeChange, afterChange, beforeRead, afterRead, beforeDelete, afterDelete. Кожен хук отримує data, req і context. Ми використовуємо строгу типізацію TypeScript, щоб уникнути помилок на етапі компіляції.
| Тип хука | Задача | Приклад використання |
|---|---|---|
beforeChange |
Трансформація даних | Генерація orderNumber, встановлення createdBy |
afterChange |
Side-ефекти | Відправка email, синхронізація з CRM, інвалідація кешу, сповіщення |
beforeRead |
Безпека | Фільтрація даних за роллю користувача |
afterRead |
Збагачення | Обчислення subtotal з items, підстановка пов'язаних даних |
beforeDelete |
Захист | Заборона видалення клієнта з активними замовленнями |
Які типові помилки трапляються при розробці хуків?
Необроблена помилка в beforeChange блокує збереження, а в afterChange може призвести до втрати даних. Ми завжди використовуємо патерн: у валідаційних хуках — throw new Error, у побічних — логування + повторна спроба. Для тривалих операцій ставимо завдання в чергу через Bull або Redis. Хук beforeRead дозволяє приховати чутливі поля для непідготовлених користувачів. Наприклад, менеджер бачить тільки свої замовлення, а адмін — всі. Це реалізується фільтрацією по req.user. Після операції afterDelete можна записати лог в окрему колекцію для аудиту.
Приклад коректної перевірки залишків:
const validateStock: CollectionBeforeChangeHook = async ({ data, req }) => { for (const item of data.items) { const { stock } = await externalApi.checkStock(item.product) if (stock < item.quantity) { throw new Error(`Недостатньо товару "${item.name}" на складі`) } } return data } Кейс: інтернет-магазин електроніки
Потрібна була генерація номера замовлення виду ELEC-XXXXX (без року, щоб не застарівати), перевірка залишків через зовнішнє API та відправка даних в 1С. Ми реалізували три хуки:- beforeChange — генерація номера і виклик API складу. Якщо залишків немає — повертаємо помилку.
- afterChange — відправка email клієнту і створення угоди в CRM.
- afterChange — запис у чергу для синхронізації з 1С (через Bull).
Всі хуки типізовані, використовують CollectionConfig. Помилки логуються в Sentry. Результат: замовлення обробляються без затримок, ручна праця виключена, а синхронізація з 1С відбувається раз на хвилину. Кастомні хуки в 3 рази швидше вирішують задачу валідації порівняно з вбудованими методами Payload.
Як впровадити кастомні хуки: покрокова інструкція
- Аналіз вимог: опишіть бізнес-логіку, визначте потрібні етапи (beforeChange, afterChange тощо).
- Проектування: спроектуйте схему даних і взаємодію із зовнішніми сервісами.
- Розробка: напишіть код хука з типізацією та обробкою помилок.
- Тестування: покрийте критичні сценарії unit-тестами.
- Деплой: впровадьте через CI/CD з автоматичною перевіркою.
Процес роботи
| Етап | Тривалість | Результат |
|---|---|---|
| Аналіз | 1 день | Специфікація хуків з урахуванням бізнес-логіки |
| Розробка | 2–3 дні | Код хуків з unit-тестами |
| Тестування | 1 день | Перевірка в staging-оточенні |
| Деплой і документація | 0.5 дня | Merge в main, опис кожного хука |
Що входить у deliverables
- Вихідний код хуків з коментарями (TypeScript).
- Тести на критичні сценарії (покриття 80%+ — тестуємо 90% сценаріїв).
- Документація: опис кожного хука, його призначення, вхідні/вихідні дані.
- Доступ до репозиторію з історією комітів.
- Підтримка протягом 2 тижнів після деплою.
Терміни та як замовити
Термін розробки хуків для однієї колекції — від 1 до 3 днів. Вартість розраховується індивідуально після аналізу вимог, орієнтовна ціна одного хука — від $200 до $500 залежно від складності. Впровадження кастомних хуків дозволяє заощадити бізнесу до $1000 щомісяця на ручних операціях. Якщо вам потрібно впровадити кастомні хуки в Payload CMS — зв'яжіться з нами для оцінки проекту. Опишіть задачу, і ми запропонуємо оптимальне рішення. Детальніше про хуки читайте в офіційній документації Payload. Замовте розробку кастомних хуків під вашу задачу — гарантуємо прозорість і якість. Кастомні хуки в Payload CMS дають змогу реалізувати бізнес-логіку в 5 разів швидше, ніж стандартні методи. Використовуйте payload cms hooks для автоматизації beforeChange, afterChange, beforeDelete та інших операцій — це в 3 рази підвищує продуктивність розробки.







