Декомпозиция Form Request в Laravel

[webdevium]

В Laravel изначально все правила валидации являются отдельными классами.
Даже если мы пишем required|string|min:1, это всё равно массив из трёх объектов.

Собственно, вопрос: что вы декомпозировали?

[agoalofalife]

Получается что я декомпозировал на уровень выше. Мы можем провалидировать именно целостные поля(email, age, city).
Насколько я знаю, это не совсем объекты, во исходниках есть папка Rule, но она содержит не сколько правил, все правила перечислены в свойствах массива класса Illuminate\Validation\Validator.
Но суть в другом, если даже мы имели возможность перечислять каждое правило как объект, все равно наличии их в двух местах нарушает принцип DRY.
Важно что field email целостный и проверяется везде одинаково что от бота что от api клиента.

[agoalofalife]

К дополнению: во фреймфорке, в совокупности со свойствами вызывается методы для проверки данных.Свойства это часть название метода проверки.
Методы содержатся в трейте ValidatesAttributes который находится в классе Illuminate\Validation\Validator. Соответственно

required|string|min:1

это три метода из трейта.

[webdevium]

А кто сказал, что наличие правила email в двух местах — это нарушение DRY?

[agoalofalife]

Нарушение не наличие правила email. А если нам понадобиться добавить еще одно правило для проверки поля с названием email(собственно он и ожидается), и это надо будет сделать в двух местах.(в двух местах добавить новое правило)

[webdevium]

Понял. Спасибо.

Идея не нова. Достаточно поискать в Laravel сообществе слова validation composite или laravel rule groups

[agoalofalife]

нашел этот пакет, не увидел работу с Form Request, вы им пользовались? можно ли его использовать с FormRequest?

[webdevium]

К сожалению, или к счастью, никогда не сталкивался с потребностью использовать свои группы правил. Не могу знать о функциональности тех пакетов.

[GoodGod]

Спасибо за статью!

А можно засунуть все группы правил в статичные методы:

class ValidationRules
{
    public static function getEmailRules(){
        return ['required', 'email'];
    }
    public static function getNameRules(){
        return ['required', 'alpha'];
    }
}

ну понятно, что ваш подход дает больше возможностей.

Мне было бы интересно еще решить проблему комбинаций, например где-то требуется email, name, age; где-то email, name, phone; где-то email, name, address, не получается ли дублирования, и можно ли как-то его уменьшить/избежать?

[agoalofalife]

А можно засунуть все группы правил в статичные методы:

Думаю что можно, получится класс который содержит список всех правил.
Вопрос в том, что мои объекты еще могут принимать зависимости в конструкторе, они должны быть как опорной информацией при валидации. Считаю — что это больше ООП подход.
Потом если представить как это будет выглядеть в клиентском коде

class UpdateUserProfile extends FormRequestDecompose
{
  public function rules(): array
  {
   return [
                ValidationRules::getEmailRules(),
		ValidationRules::getNameRules()
	 ];
  }
}

Тут мне не нравится что в клиентском коде повторяется название класса ValidationRules, так как он везде повторяется, то его становится много и код более избыточен.
Потом другой программист(новый) может подумать что тут набор правил для валидации email во всех ситуациях.
И еще почему то противится мое нутро использовать так, в любом случае это мое мнение.

Мне было бы интересно еще решить проблему комбинаций, например

Думаю что это не совсем дублирование, так как ValidatorValue самодостаточная единица и ее можно использовать везде. Его использование подразумевается именно в клиентском коде. В принципе в этом и смысл, их комбинировать между собой. Для примера можно думать о них как об объектах значениях из DDD, конечно это не тоже самое, но пользуемся мы ими похоже. Создали объект, передали информацию для валидации, он просто провалидировал — не изменяя никаких данных. Другое дело что он привязан к структуре Laravel. Надеюсь не запутанно объяснил.

[toratoda]

Я понял почему не сделали разбиение на UpdateNameRequest, UpdateEmailRequest, UpdateAgeRequest унаследованных от FormRequest

[yzen_dev]

По-моему, это обертка ради обертки. Подобные реализации избыточны.
Сократить условный 'required|string' ради чего? Всю локализацию ошибок я и так могу отдельно описать.
Не стоит забывать про принцип KISS :)

[agoalofalife]

Можете привести свой пример как решить проблему из статьи?

[toratoda]

Проблему повторения группы правил, как писал выше - создайте UpdateEmailRequest extends FromRequest и используйте его для проверки email

[agoalofalife]

Возможно проблема в том что я не очевидно обозначил, но Form Request не работает с botman. Это связано с тем что ответы об ошибках выводятся иначе чем во фреймворке. Ситуация такая что в одном месте мы можем использовать Form Request a в другом только обычную валидацию