Увійти Реєстрація
Блог Серії
Кар'єра
Вакансії Компанії
Навчання
Документація Співбесіди Тестування Відео
Екосистема
Пакети Ресурси Проєкти Інструменти Події
Інше
Про нас Реклама
Tips 05 серпня 2026

Умовне завантаження зв'язків

Потрібні різні зв'язки в залежності від контексту?

Використовуйте when() для умовного eager loading.

Типові кейси:

  • Admin vs звичайний користувач
  • API vs web
  • Різні рівні деталізації

Перевага: одна логіка запиту, різні варіанти відповіді.

// За роллю
$posts = Post::query()
  ->when(auth()->user()->isAdmin(), function ($query) {
    $query->with(['author', 'drafts', 'revisions']);
  })
  ->when(!auth()->user()->isAdmin(), function ($query) {
    $query->with('author:id,name');
  })
  ->get();

// За параметрами запиту
$posts = Post::query()
  ->when(request()->has('include_author'),
    fn($q) => $q->with('author')
  )
  ->when(request()->has('include_comments'),
    fn($q) => $q->with('comments.user')
  )
  ->get();

Читати в документації

Коментарі

Увійдіть, щоб залишити коментар

Будьте першим, хто залишить коментар!

Інші поради

Tips 14 жовтня 2026

`prohibits` - взаємовиключна валідація

Користувач може платити карткою АБО PayPal. Не обома.

Писати кастомну логіку? Є вбудоване правило.

prohibits гарантує, що поле не може бути присутнім разом з іншим.

Коли корисно:

  • Взаємовиключні способи оплати
  • Або email, або телефон
  • Умовні обмеження полів

Схожі правила:

  • required_without — потрібно A, якщо B немає
  • required_with — потрібно A, якщо B є
  • prohibits — A забороняє B

Порада: комбінуйте з required_without для сценарію “або A, або B, але не обидва”.

public function rules()
{
  return [
    'card_number' => 'prohibits:paypal_email',
    'paypal_email' => 'prohibits:card_number',

    'email' => 'required_without:username|prohibits:username',
    'username' => 'required_without:email|prohibits:email',
  ];
}
Tips 12 жовтня 2026

`bail` - зупинити валідацію після першої помилки

У поля email 5 правил. Усі падають — користувач бачить 5 помилок.

Це плутає.

bail зупиняє валідацію поля на першій помилці.

Навіщо:

  • Кращий UX — по одній помилці
  • Продуктивність — не запускаємо дорогі перевірки
  • Чіткіші повідомлення

Як працює:

Додайте bail першим правилом для поля.

Порада: ставте перед дорогими правилами типу exists:, unique: або кастомними перевірками з API.

public function rules()
{
  return [
    'email' => 'bail|required|email|max:255|unique:users',
    'username' => [
      'bail',
      'required',
      'min:3',
      Rule::unique('users')->ignore($this->user),
      new CheckExternalAPI,
    ],
  ];
}
Tips 09 жовтня 2026

`prepareForValidation()` - чистимо дані до валідації

Телефон приходить як "(123) 456-7890", а в БД потрібен "1234567890".

Санітизація в контролері? Це вже запізно.

prepareForValidation() змінює дані запиту до запуску правил.

Коли корисно:

  • Нормалізація телефону
  • Прибирання пробілів
  • Конвертація типів
  • Додавання обчислюваних полів

Важливо:

Виконується до валідації — ідеально для нормалізації.

Порада: merge() додає/оновлює поля, replace() повністю замінює масив даних.

protected function prepareForValidation()
{
  $this->merge([
    'phone' => preg_replace('/[^0-9]/', '', $this->phone),
    'slug' => Str::slug($this->title),
    'price' => (float) $this->price,
    'name' => trim($this->name),
    'email' => strtolower(trim($this->email)),
  ]);
}
Tips 07 жовтня 2026

`exclude()` - прибираємо поля з валідованих даних

У формі є CSRF-токен та допоміжні поля. Ви не хочете, щоб вони потрапили у validated().

exclude_if, exclude_unless прибирають поля умовно.

Коли корисно:

  • Прибрати UI-only поля
  • Виключити поля залежно від ролі
  • Не логувати чутливі поля
  • Тримати валідовані дані “чистими”

Доступні правила:

  • exclude — завжди прибирає
  • exclude_if — прибирає, якщо умова істинна
  • exclude_unless — прибирає, якщо умова хибна
  • exclude_with — прибирає, якщо інше поле присутнє

Порада: краще за ручний unset() після валідації.

public function rules()
{
  return [
    'name' => 'required',
    'admin_notes' => 'exclude', // не потрапить у validated()
    'is_admin' => 'exclude_unless:user.role,admin',
    'card_number' => 'exclude_if:payment_method,cash',
    'paypal_email' => 'exclude_if:payment_method,card',
  ];
}
Tips 05 жовтня 2026

`after()` - хук валідації після проходження всіх правил

Треба перевірити комбінацію полів? Або пов’язані записи в БД?

Звичайні правила працюють незалежно. Хук after() запускається після того, як усі правила пройшли.

Коли корисно:

  • Валідація кількох полів разом
  • Перевірки в БД
  • Складна бізнес-логіка
  • Кастомні повідомлення помилок на основі кількох полів

Суть:

Callback отримує Validator. Помилки додаються вручну.

Порада: after() ідеальний для валідації, що залежить від кількох полів або запитів до БД.

public function withValidator($validator)
{
  $validator->after(function ($v) {
    if ($this->start_date > $this->end_date) {
      $v->errors()->add(
        'end_date',
        'Дата завершення має бути після початку.'
      );
    }

    $total = $this->quantity * $this->price;
    if ($total > 1000 && ! $this->has_approval) {
      $v->errors()->add(
        'has_approval',
        'Замовлення понад $1000 потребують підтвердження.'
      );
    }
  });
}
Завантаження...