Валідація — це момент, де Laravel починає захищати твій проєкт від хаосу. Користувач може відправити порожні поля, занадто довгий текст, неправильну дату, небезпечні символи або взагалі підроблений запит. Якщо ти не перевіряєш дані, ти отримуєш “биті” записи в базі, дивні баги, дірки в безпеці і постійні виправлення “заднім числом”. Тому валідація — це не прикраса, а обов’язкова частина будь-якої форми.
У Laravel валідацію можна писати прямо в контролері, але для реального проєкту стандарт — FormRequest. FormRequest — це окремий клас, де живуть правила перевірки і, за потреби, перевірка авторизації. Чому це краще: контролер залишається чистим, правила не дублюються, їх легко знайти і змінювати, а код стає передбачуваним для всієї команди.
Починається все з логіки “що ми перевіряємо”. Ти береш форму і виписуєш поля: назва, опис, дата, статус, файл, slug тощо. Для кожного поля ти визначаєш мінімум: чи обов’язкове воно, який тип, яка довжина, чи має бути унікальним, чи має входити в список дозволених значень. Це і є правила. Без цієї дисципліни новачки роблять дві крайності: або не перевіряють нічого, або роблять правила “на око”, а потім форма не працює.
FormRequest створюється як окремий клас. Логічно уяви: для створення є один набір правил, для оновлення — інший. Наприклад, поле slug має бути унікальним, але при редагуванні ти повинен дозволити “той самий slug” для поточного запису. Тому часто роблять StoreSomethingRequest і UpdateSomethingRequest. Це не бюрократія, це спосіб уникнути помилок.
У FormRequest є два головні методи. authorize() відповідає за те, чи має користувач право виконати дію. Якщо ти повернеш false, Laravel дасть 403. На старті можна ставити true, а доступи робити через middleware/policies, але важливо розуміти: FormRequest може бути ще одним “запобіжником” для конкретної дії. rules() — це серце: тут ти описуєш, які правила застосовуються до кожного поля.
Правила у Laravel читаються як список вимог. Наприклад, required|string|max:255 означає, що поле обов’язкове, має бути рядком, і не довше 255 символів. nullable означає, що поле може бути порожнім. integer — що має бути числом. date — що це дата. in:published,draft — що значення повинно бути одним з дозволених. Логіка проста: ти не даєш системі приймати випадкові значення.
Окремий блок — унікальність і зв’язки з базою. unique гарантує, що значення не повторюється в таблиці, наприклад для slug або email. На створенні це прямолінійно, на оновленні потрібно “ігнорувати” поточний запис, інакше ти сам себе заблокуєш. Це найтиповіша помилка новачків: форма редагування постійно каже “вже існує”, хоча це той же запис.
Далі — повідомлення про помилки. Стандартні повідомлення Laravel нормальні, але в реальному продукті ти хочеш людську мову і конкретику. У FormRequest є метод messages(), де ти можеш задати свої тексти для конкретних правил. Це важливо, бо “The title field is required” не завжди прийнятно, а “Вкажіть заголовок” зрозуміло будь-кому. Плюс ти можеш налаштувати назви полів через attributes(), щоб повідомлення були “не про title”, а про “Заголовок”.
Тепер найважливіше для UI: що відбувається, коли валідація не проходить. Laravel автоматично робить redirect назад на форму і кладе в сесію два набори даних: errors (список помилок) і old (старі введені значення). Тобто тобі не треба вручну “переносити” помилки — треба лише правильно їх показати в Blade.
errors у Blade — це об’єкт з помилками по полях. Ти можеш показувати загальний список помилок зверху форми або показувати помилку біля конкретного поля. Для нормального UX правильніше показувати біля поля: користувач одразу бачить, що саме не так. Плюс можна підсвітити поле червоною рамкою, якщо є помилка, — це робить форму зрозумілішою без текстових пояснень на півекрану.
old() — це функція, яка дістає попереднє значення поля з сесії після помилки. Тобто користувач ввів 10 полів, помилився в одному, натиснув “зберегти”, і форма повернулась із заповненими 9 полями. Це критично для будь-якої адмінки. Якщо ти не використовуєш old(), люди будуть ненавидіти форму, бо вона “скидає все” через одну дрібницю.
Для edit-форм є правильна схема заповнення. Спочатку ти показуєш old('field'), якщо він існує (це означає, що форма вже відправлялась і впала). Якщо old нема — показуєш значення з моделі. Це знімає головний біль: форма не губить введене, але і не показує порожньо, коли ти просто зайшов редагувати запис.
Ще один важливий момент — масиви, чекбокси і select. Чекбокс, якщо не відмічений, не відправляється взагалі, і новачок часто ловить “чому не зберігається false”. Тут потрібні або дефолти, або hidden-поля, або правильна логіка в сервісі. Select-поля мають перевірятися через in: або через існування в таблиці (exists:), щоб не можна було підсунити значення, якого не має бути.
Практичний порядок роботи, який варто привчити робити завжди. Спочатку ти робиш форму і виписуєш поля. Потім створюєш FormRequest і прописуєш rules. Потім в контролері приймаєш саме цей FormRequest, а не “голий” Request, і береш перевірені дані. Після цього у Blade підключаєш показ помилок і old(). І тільки потім займаєшся “красивим UI”, бо без валідації UI — це декорація.
Висновок: FormRequest — це мінімальний стандарт для нормального Laravel-проєкту, бо він тримає правила в одному місці і не дає контролерам перетворюватися на смітник. Правила захищають базу і бізнес-логіку, повідомлення роблять UX людським, а old()/errors дають нормальну поведінку форм після помилки. Якщо ти освоїш це на старті, ти перестанеш боятися великих форм і почнеш робити адмінку швидко і стабільно.
