Неортодоксальный Eloquent. Часть 1

[KoIIIeY]

Если, например, для Антарктиды нам нужно поменять местами вторую и третью строки, мы можем сделать это в AsLines, и нам не придётся корректировать blade шаблон. Нестандартное мышление может значительно упростить визуализацию пользовательских интерфейсов и предотвратить создание слишком умных интерфейсов, которые, как правило, не приветствуется и считаются антипаттерном.

Мы уже давно живем в мире, в котором фронт отдельно, бэк отдельно.

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

А хочешь обертку? Сделай getAttributeName, не создавай для этого еще один класс, вот когда появится миллион различных видов вывода, тогда и сделаешь.

[IgorAlentyev]

Недооценённый комментарий. Не нужно плодить сущности пока в этом нет явной необходимости

[igor-D]

Полностью поддерживаю. Что бы там ни говорили, а абстракции и доп классы часто только усложняют процесс понимания кода в итоге, что выражается в большей трате времени. Многое, что тут описано, вполне себе можно решить без доп классов и абстракций и понять потом будет проще в разы, просто прочитав код. Пусть не такой "красивый", но зато простой и понятный. Некоторые моменты интересны, особенно с midleware, но остальное выглядит как-то высосанным из пальца. Напоминает фанатичные попытки избавиться от циклов, когда все пихают в колбэк и в итоге каждое действие надо разбирать код и читать документации, чтобы узнать что на самом деле тут происходит.

[Fubu_By]

Это же пример, раскрывающий возможности laravel, а не продакшн код. А как писать код, это вы будете уже на конкретном проекте...

[indigoram89]

Спасибо

[koreychenko]

Вот честное слово в Doctrine Speсifications это реализовано как-то проще, без необходимости пилить под каждое "человекочитаемое" условие отдельный класс. Часто делают просто один класс с кучей статических методов, возвращающих условия.

[Helldar]

В Ларе также. Кроме того, автор оригинала взял для примера поля user_id и verified_at. Не знаю как у него, а все разрабы, с кем я когда-либо работал, сразу поймут что за условия whereNull и whereNotNull в связке с этими именами и пилить отдельный класс это оверхед.

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

Для примера, в недавно написанном моём коде есть примерно такие строки:

return Product::query()
    ->where(...)
    ->when(true, fn (Builder $builder) => $this->sorter($sortType)
        ->category($category)
        ->priceLevel($priceLevel)
        // ...
        ->toBuilder()
    )    
)

protected function sorter(SortEnum $type): Builder
{
    return match($type) {
        SortEnum::Popular => new Popular(),
        SortEnum::LowPrice => new LowPrice(),
        // ...
    }
}

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