Започаткую рубрику #бидло_промпт_інженірінг

Якщо впізнали себе і маєте подібний досвід - кидайте скріншотики в коментарі 😁

Пофіксив багу з генерацією HTML для форми віджета. Оновлюйтесь, якщо встигли встановити, звісно 😆

Підсумки періоду. Писати код самостійно — круто 😅
Добраніч і тихої ночі!

Якщо працюєте з Livewire, то коротка новина.

Відбувся реліз Livewire 4

https://github.com/livewire/livewire/releases/tag/v4.0.0

Вау! Дуже класна презентаха. Слідуйте інструкціям і гортайте сторінки. Дуже топ! Інформативно та зрозуміло.

https://yermilov.github.io/pragmatic-vibe-clauding-ua

Етюди сьогодення розробників в Україні. Як ви, шановні?

Не пройшов і рік, як наш проєкт нарешті майже мігранув на Laravel 12.

Мені скоро огляд 13ї дарки робити, а тут слоупок паті в реалі.

А шо у вас? Всі на останній ларці в проєктах у себе?

Смачної кавусі і боже збав вас сьогодні шось деплоїти. Світла нема, інтернету дефіцит, а ви ще дебажити зібрались. Ну майте совість!

Тут підписник цікавиться: у всіх такі ПМи? 🫠

Ну що, пігулочки запили смачною кавусею і погнали ту айтішку шабуршить! ☕️

#laratip

Laravel Validation Hack: Коли `required_if` вже не стягує

Знаєте ці моменти, коли валідація форми перетворюється на спробу розгадати ієрогліфи? Коли у вас є поле, яке стає обов'язковим тільки якщо "зірки зійшлися", а клієнт вибрав тип аккаунту "Platinum Business Plus"?

Звісно, можна напхати required_if:type,customer, але що як умова складніша? Ось тут на сцену виходить метод sometimes().

Суть методу

sometimes() дозволяє додавати правила валідації лише за умови, що переданий колбек поверне true. Це набагато гнучкіше за стандартні required_with чи required_unless, оскільки ви працюєте з чистим PHP всередині замикання.

Аналіз кейсів зі скріна:

1. Ізольована логіка: Правило required|email активується лише для типу customer. Це чистіше за довгі рядки валідації, особливо коли логіка виходить за межі простої перевірки "рівно/не рівно".

2. Групова валідація: Можна передати масив полів ['phone', 'address']. Це ідеально для ситуацій, коли вибір однієї опції (наприклад, способу доставки) робить обов'язковим цілий блок даних.

3. Complex Logic: В замикання приходить об'єкт $input (екземпляр Fluent). Тут можна будувати складні ланцюжки: перевіряти вкладені параметри, бізнес-ліміти чи навіть робити запити до БД. На скріні бачимо комбінацію типу аккаунту та фінансового порогу — реалізувати таке через стандартні string-правила майже неможливо.

Senior Tips

Form Requests: Не пишіть валідатор у контролері. Використовуйте FormRequest та метод withValidator($validator). Саме там цим правилам і місце, щоб тримати контролер суто для координації потоку.

DX та типи: У Symfony ми б городили FormEvents::PRE_SUBMIT або складні Callback констрейнти. Laravel дає лаконічний інтерфейс, але пам'ятайте про читабельність — якщо умова в sometimes() займає 20 рядків, краще винести її в окремий приватний метод.

Legacy: Якщо бачите в проєкті if ($request->has(...)) { $rules['field'] = ... } — це прямий кандидат на рефакторинг через sometimes().

Такий підхід робить валідацію декларативною та легшою для тестування.

Час кохве наколотити і вджобувати. Гарного дня, колеги! ☕️

Для такого нейромережі нам потрібні 💪🏻

#laratip

Custom Validation Rules: від костилів до елегантних рішень

Коли вбудованих required, string або exists стає замало, у нас є два шляхи. Вибір залежить від того, чи збираєтесь ви перевикористовувати цю логіку.

1. Inline-валідація (Closures) Підходить для унікальної логіки "тут і зараз".

Плюс: Швидко, не засмічує структуру проєкту.

Мінус: Важко тестувати окремо, копіпаст — гріх. У замикання прокидається $fail. Якщо викликали — валідація не пройшла.

2. Rule Objects (Artisan make:rule) Це вже дорослий підхід. Але зверніть увагу: на скрині старий підхід з passes() та message(). У сучасних версіях Laravel ми використовуємо один метод validate(string $attribute, mixed $value, Closure $fail): void.

Senior Tips:

Якщо логіка валідації потребує запитів до БД — виносьте в Rule-клас.

Використовуйте Rule::macro, якщо хочете додати метод у загальний білдер валідатора.

Для складних DTO та Domain-Driven Design валідацію краще тримати ближче до шару Application, а не тільки в Request-класах.

Що по коду на скрині?
Приклад з strtoupper — ок для демо, але в реалі враховуйте локалізацію та мультибайтові рядки (mb_strtoupper).

Валідувати кейс юзернейма — специфічний кейс, зазвичай ми просто робимо $request->merge() або валідуємо через Regex.

Продовжуємо корисне впровадження АІ

Пишіть ваші жарти в коментарях

Я пушу не протестований код в пʼятницю.

Девопс, який вночі на чергуванні:

Ну не деплоїти ж сьогодні, правда?😉💪🏻

І знову робочий день. Тримати стрій!