KRUHLYK 🇺🇦

#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 Boost до версії 2.0. Це зекономить вам купу токенів ваших ШІшок! ПиСи: всі переходять від глобальних гайдлайнів до опису скілів. І… це реально класно працює 😎

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

Ну що, понеділок. Час попрацювати! ☕️

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

Я пушу не протестований код в пʼятницю. Девопс, який вночі на чергуванні:

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

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

#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.

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

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

#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(). Такий підхід робить валідацію декларативною та легшою для тестування.

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

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

Не пройшов і рік, як наш проєкт нарешті майже мігранув на Laravel 12. Мені скоро огляд 13ї дарки робити, а тут слоупок паті в реалі. А шо у вас? Всі на останній ларці в проєктах у себе? Смачної кавусі і боже збав вас сьогодні шось деплоїти. Світла нема, інтернету дефіцит, а ви ще дебажити зібрались. Ну майте совість!

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

Вау! Дуже класна презентаха. Слідуйте інструкціям і гортайте сторінки. Дуже топ! Інформативно та зрозуміло. https://yermilov.github.io/pragmatic-vibe-clauding-ua/#slide-10

Якщо працюєте з Livewire, то коротка новина. Відбувся реліз Livewire 4 https://github.com/livewire/livewire/releases/tag/v4.0.0