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

Не пройшов і рік, як наш проєкт нарешті майже мігранув на 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.

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

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

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

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

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

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

Скоріше оновлюйте Laravel Boost до версії 2.0. Це зекономить вам купу токенів ваших ШІшок!

ПиСи: всі переходять від глобальних гайдлайнів до опису скілів. І… це реально класно працює 😎

Попрацював. Пішов я спати. Тихої ночі, колеги!

Перше правило продакшн-клубу: нічого не чіпати в п'ятницю

#laratip

Валідація пароля: робимо це правильно в Laravel

Багато хто досі перевіряє поточний пароль вручну в контролері через Hash::check. Я дуже часто це бачу у ваших кодових базах, коли ми працюємо на менторських програмах. Це легасі-підхід, який роздуває код. На скріні — чистий спосіб через Form Request.

Що тут відбувається:

current_password: вбудоване правило Laravel. Воно автоматично звіряє введене значення з хешем пароля автентифікованого користувача. Більше ніяких ручних перевірок.

confirmed: стандарт, що вимагає наявності поля new_password_confirmation. Позбавляє від помилок при вводі нового пароля.

different:current_password: маст-хев для UX та безпеки. Не даємо юзеру змінити пароль на той самий, що вже встановлений.

unique:users,email: перевірка унікальності імейла. Але зверни увагу: якщо це оновлення профілю, тут бракує ігнорування поточного ID користувача, інакше валідація впаде на "email вже зайнятий".

Senior-порада:

Якщо ви використовуєте Clean Architecture або DDD, не затягуйте логіку Hash::make() у валідатор. Валідатор лише перевіряє вхідні дані. Сама ж операція хешування та збереження має жити в Action-класі або Domain Service.

Для проектів з високим навантаженням на БД, правило unique краще доповнити unique:users,email,'.auth()->id(), щоб валідатор знав, що ми оновлюємо саме цей запис.

Що ж, понеділок знову увірвався коли його не очікуєш і знову без світла на дового 🙄

І тут нам батя Тейлор анонсував, що нам треба переставати звикати до властивостей в класах Laravel і переповзати на використання атрибутів.
При тому, залишається зворотна сумісність з використанням властивостей.

І знаєте що? Мені таке дуже подобається. На мою скромну думку, код з використанням атрибутів стає більш читабельним та передбачуваним. PHP все біль більше стає дорослою, зрілою мовою з сімейства C.

А якої думки ви з цього питання, пишіть в коментарях! Гарного понеділка та смачної кави!

https://github.com/laravel/framework/pull/58578

Може хтось шукає проєкт чи може порекомендувати?