Junior: питання на співбесіді з теми «Валідація»

Валідація перевіряє вхідні дані за набором правил перш ніж їх використати. Laravel має багату систему правил і кілька способів валідації.

1. Метод validate() прямо в контролері (найпростіше):

$validated = $request->validate([
    'title' => ['required', 'string', 'max:255'],
    'email' => ['required', 'email', 'unique:users,email'],
    'age'   => ['nullable', 'integer', 'min:18'],
]);

Якщо перевірка не пройдена, Laravel автоматично:

• для веб-запитів - робить редирект назад зі старими даними та помилками в сесії (доступні через $errors у Blade);
• для API (запит очікує JSON) - повертає відповідь 422 зі структурою { "message": ..., "errors": {...} }.

2. FormRequest - для складнішої логіки правила й авторизацію виносять в окремий клас:

php artisan make:request StorePostRequest

public function rules(): array
{
    return ['title' => ['required', 'max:255']];
}

Це розвантажує контролер. Є десятки вбудованих правил (required, email, unique, exists, confirmed, date), власні правила та умовна валідація.

Докладніше в документації: Валідація

Коли валідація не проходить, Laravel перенаправляє користувача назад, кладе помилки в сесію й «спалахом» зберігає введені дані. У шаблоні їх лишається вивести.

<input name="email" value="{{ old('email') }}" @class(['is-invalid' => $errors->has('email')])>

@error('email')
    <p class="error">{{ $message }}</p>
@enderror

Що тут працює:

• $errors доступна в кожному шаблоні групи web - її додає middleware ShareErrorsFromSession;
• @error виводить перше повідомлення для поля в змінній $message;
• old('email') повертає значення, яке користувач надіслав минулого разу. Другим аргументом передають значення за замовчуванням - наприклад, old('email', $user->email) у формі редагування.

Чого не повертають через old(): паролі. Laravel не зберігає в сесії поля password і password_confirmation.

Для JSON-запитів перенаправлення немає - повертається відповідь 422 з об'єктом errors, і показ помилок бере на себе фронтенд.

Докладніше в документації: Відображення помилок валідації

Три правила відповідають на різні питання: чи має поле бути, чи може воно бути порожнім, і чи перевіряти його взагалі.

$request->validate([
    'title'      => ['required', 'string'],      // має бути й не порожнє
    'publish_at' => ['nullable', 'date'],        // може бути порожнім, інакше - дата
    'nickname'   => ['sometimes', 'string'],     // перевіряється, лише якщо поле прийшло
]);

• required - поле має бути присутнім і непорожнім (не null, не порожній рядок, не порожній масив).
• nullable - null дозволений, і решта правил для нього не виконуються.
• sometimes - якщо ключа в запиті немає, правила поля не запускаються взагалі.

Чому nullable потрібен так часто: глобальні middleware TrimStrings і ConvertEmptyStringsToNull перетворюють порожнє поле форми на null. Без nullable правило date вважатиме null недійсною датою, хоча поле необов'язкове.

Де sometimes доречний: часткові оновлення (PATCH), коли клієнт надсилає лише змінені поля. sometimes|required означає «якщо поле прийшло, воно не може бути порожнім».

Докладніше в документації: Зауваження про необов'язкові поля