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

Слабое место подобных примеров, на мой взгляд, в том, что для начинающего разработчика, не очень знакомого с концепцией контейнера и dependency injection, идея замены одной реализации сервиса на другую не очень близка. В голову сразу приходит, что у меня-то сейчас один класс используется — вот этот. Когда надо будет другой, тогда и контейнер сделаю, а пока буду явно обращаться к данному классу. И это, как мне кажется, вполне нормальный ход мыслей.

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

Допустим, вы в своих проектах практикуете TDD. И у вас, помимо всех остальных тестов, проверяющих всё на свете, есть тест создания какой-нибудь модели через API Post, или просто через форму. И вот внезапно вам понадобилось подцепить на эту форму проверку reCAPTCHA против спаммеров. Реализовать саму логику работы во фронте (на Vue.js) и проверку полученного токена в бэке — нетрудно (вот пример).

А вот тест создания модели (и все связанные с этим роутом/формой тесты) — немедленно поломаются. Потому что где вы возьмете валидный ключ капчи для проверки, если он в тестовом режиме не прилетает из фронта?

Можно было бы попытаться организовать прохождение капчи для бэк-энд тестов (хотя я не совсем понял, как это именно в случае reCAPTCHA сделать). Но: — от этого нет пользы помимо тестирования; — у нас нет задачи тестировать гугл-капчу в каждом тесте бэкенда, который проверяет работу методов post/put у каждой защищенной капчей формы; — для тестирования внешнего сервиса достаточно одного теста интеграции — что мы верно всё подключили — а остальное есть забота разработчика внешнего сервиса; — если каждый тест формы будет проверять ключ капчи через сервис гугла, тесты внезапно станут значительно дольше работать.

В общем, представляется что не нужно это делать. Вот тут-то и возникает необходимость в подмене живой капчи — фейковой. И это как раз неплохо иллюстрирует концепцию сервис-контейнеров и внедрения зависимостей. Далее — код.

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

Метод morphWith

Конкретно этот метод есть в доках, но он появился совсем недавно, в версии 5.8.22 (а текущая — 5.8.25) и не сразу нашёлся именно поэтому. Суть вот в чем. Допустим, у нас есть модель Event, которая радостно полиморфирует с другими моделями. Для неё отношения описаны так:

class Event extends Model
{
    protected $with = ['parent'];

    public function parent() {
        return $this->morphTo();
    }

    // ...
}

Как мы видим, благодаря свойству $with модель будет сразу загружаться с родителем, независимо от того, что это за родитель. Однако что, если нам нужно разом загрузить и какие-то отношения этого (неопределенного пока) родителя с другими моделями. Допустим, модели Payment и Deadline связаны полиморфно с Event, и в то же время модель Payment связана с моделью Order, а Deadline — скажем, с моделью User. Примерно так:

class Payment extends Model
{
    public function events() {
        return $this->morphMany('App\Event', 'parent');
    }

    public function order() {
        return $this->belongsTo(Order::class);
    }

    // ...
}

// (в другом, конечно, файле)

class Deadline extends Model
{
    public function events() {
        return $this->morphMany('App\Event', 'parent');
    }

    public function User() {
        return $this->belongsTo(User::class);
    }

    // ...
}

И мы хотим, чтобы платежи грузились с заказами, а дедлайны — с пользователями. Конечно, мы могли бы воспользоваться свойством $with для моделей Payment и Deadline. Но что если в Order и User уже используется свойство $with для загрузки платежей и дедлайнов? Тогда мы не сможем воспользоваться этим свойством, поскольку уйдем в рекурсию.

Тут-то и поможет нам метод morphWith():

$events = Event::query()
            ->with(['parent' => function (MorphTo $morphTo) {
                $morphTo->morphWith([
                    Payment::class => ['order'],
                    Deadline::class => ['user'],
                ]);
            }])
            ->get();

То есть что мы тут делаем? Мы вызываем для отношения MorphTo метод morphWith() и для каждого класса родителя, для которого нужно грузить его отношения, указываем массив из этих отношений. И они грузятся.

А что если надо отменить eager loading

Может возникнуть и прямо противоположная проблема. Допустим, мы автоматически грузим модель Payment из Order через свойство $with — это будет работать всякий раз, когда модель заказа загружается. Но что если нам в данном конкретном случае нужно автоматически загрузить заказы для группы платежей, и не попасть при этом ни в рекурсию, ни в «проблему N+1 запросов»?

Очевидно, нужно отключить eager-loading. Вот два примера, как можно это сделать.

1) Если может возникнуть рекурсия из-за $with, можно отключить автозагрузку прямо в объявлении отношения:

public function order() {
    return $this->belongsTo(Order::class)->setEagerLoads([]);
}

Здесь мы говорим, что при загрузке заказов для данных моделей, не нужно автоматически грузить никакие модели, связанные с заказами (и перечисленные в Order::$with). Кстати, вместо пустого массива мы можем передать массив из отношений, которые всё же нужно загрузить, ограничив таким образом автозагрузку заданным списком.

2) Если же мы прогружаем отношения явным образом с помощью метода load(), можно отключить автозагрузку вот так:

$payment->load(['order' => function ($query) {
    $query->setEagerLoads([]);
}]);

Напоследок замечу вот еще что. Хотя свойство $with и довольно удобно в целом, так как работает автоматически, бездумное его использование представляется частным случаем преждевременной оптимизации. Когда мы не знаем, как часто и какие зависимости нам потребуются, велик соблазн пихнуть их все в массив $with и забыть. Однако позже, при описании уже реальных кейсов, вполне может возникнуть ситуация, когда отношения, перечисленные в автозагрузке придётся удалять и переделывать одно за другим.

Не нужно, в общем, торопиться с оптимизацией.

Допустим, вы из контроллера возвращали коллекцию моделей в JSON, вот так:

public function index() {
    $posts = Post::all();

    // что-то делаем с постами

    return response()->json($posts, 200);
}

А на стороне фронт-энда работали с получившимся массивом, и всё было хорошо.

И вдруг в один не очень прекрасный день массив во фронт-энде внезапно превратился вот в такой объект:

{
    1: {id: 1, ...},
    2: {id: 5, ...},
    3: {id: 6, ...},
    4: {id: 12, ...},
    // ...
}

И всякие там posts.forEach() во фронт-энде сломались.

В первую очередь, нужно посмотреть на методы коллеций, применяемые к $posts. Если вы использовали filter(), или forget(), или возможно reject(), то эти методы сохраняют ключи элементов получившейся коллекции в тех значениях, что были до изменений. То есть индексированный массив превращается в ассоциативный. Вот чтобы сохранить эти ключи, в JSON и отправляется такой дурацкий объект.

А чтобы сбросить ключи и снова сделать массив индексированным, нужно воспользоваться методом values():

public function index() {
    $posts = Post::all();

    $filtered_posts = $posts->filter(function (Post $post) {
        return $post->published;
    });

    return response()->json($fitlered_posts->values(), 200);
}

Помимо других полезных свойств моделей, таких как $with или $guarded, есть в Laravel такая приятная мелочь для связанных моделей как свойство $touches. Как гласит документация, достаточно перечислить в этом свойстве отношения с другими моделями, и при обновлении данной модели все перечисленные связанные с ней — также обновятся (обновится значение updated_at). То есть для данного примера (из документации):

class Comment extends Model
{
    /**
     * All of the relationships to be touched.
     *
     * @var array
     */
    protected $touches = ['post'];

    /**
     * Get the post that the comment belongs to.
     */
    public function post()
    {
        return $this->belongsTo('App\Post');
    }
}

при обновлении или создании комментария, обновится модель Post.

А вот что в документации не написано — так это то, что помимо обновления поля updated_at, для связанной модели выстрелит событие saved. Причём, выстрелит только оно, а created и updated — нет. И это может быть полезно, например, вот зачем.

Допустим, у нас есть несколько разных моделей, которые могут быть отмечены тегами из пакета Spatie / Laravel Tags. Тогда эти модели будут состоять с тегами в полиаморных полиморфических отношениях, описываемых в трейте HasTags вот так:

public function tags(): MorphToMany
{
    return $this
        ->morphToMany(self::getTagClassName(), 'taggable')
        ->ordered();
}

Обновлять, скажем, новость, когда ей присвоен новый тег (скажем, методом syncTags()) — вполне нормальное желание. Можно по событию обновить зависимую сущность какую-нибудь, или просто кэш почистить.

Но напрямую мы присвоить модели Tag свойство protected $touches = ['posts']; не можем, потому что на этой модели не реаловано обратное полиморфическое отношение. Реализуем его отдельно для моделей постов:

public function posts()
{
    return $this->morphedByMany(Post::class, 'taggable', 'taggables', 'tag_id');
}

Теперь при добавлении модели Post нового тега, сама модель будет обновлена и произойдет событие saved.

К сожалению, в ходе экспериментов мне не удалось описать общее полиморфическое отношение с помощью morphTo() так, чтобы не реализовывать отношение для каждой использующей теги модели. Видимо, если нужно чтобы работало свойство $touches — придется реализовать отношение для каждого родителя, которого нужно потрогать.

Довольно часто встречается задача реализации ин-плейс-редактирования. То есть когда кликнули например два раза на пункт списка, и текст тут же заменился редактором, мы его поменяли, нажали enter, сохранили.

Сделать это во Vue.js несложно: рядом с каждым редактируемым пунктом выводится инпут, и в v-show указываются противоположные условия. А по двойному клику значение условия изменяется. Например:

<template>
<!-- ... -->
    <ul>
        <li v-for="(item, index) in items" :key="item.id">
            <div @dblclick="editTitleMode(item)">
                <div v-show="!item.edit_mode">{{ item.title }}</div>
                <div v-show="item.edit_mode">
                    <input v-model="item.title" @keyup.enter="saveItemTitle(item)" type="text" />
                </div>
            </div>
        </li>
    </ul>
</template>
<script>
    export default {
        data() {
            return {
                items: []
            }
        },
        methods {
            editTitleMode: function (item) {
                this.$set(item, 'edit_mode', true);
            },
            saveItemTitle: function (item) {
                // Do the saving
                item.edit_mode = false;
            }
        }
    }
</script>

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

У компонентов Vue.js есть массив this.$refs, содержащий элементы с заданным атрибутом ref. Тогда найти нужный элемент и поставить на него фокус можно вот так:

<template>
<!-- ... -->
    <ul>
        <li v-for="(item, index) in items" :key="item.id">
            <div @dblclick="editTitleMode(item)">
                <div v-show="!item.edit_mode">{{ item.title }}</div>
                <div v-show="item.edit_mode">
                    <input :ref="'input_item_' + item.id" v-model="item.title" @keyup.enter="saveItemTitle(item)" type="text" />
                </div>
            </div>
        </li>
    </ul>
</template>
<script>
    export default {
        // ...
        methods {
            editTitleMode: function (item) {
                this.$set(item, 'edit_mode', true);
                this.$refs['input_item_' + item.id][0].focus();
            },
            saveItemTitle: function (item) {
                // Do the saving
                item.edit_mode = false;
            }
        }
    }
</script>

Правда, если добавить этот код в метод, по которому показывается инпут, установки фокуса не произойдет. Всё дело в том, что в момент вызова метода editTitleMode(), значение item.edit_mode, используемое в v-show уже изменилось, но Vue.js еще не выполнил цикл проверки реактивных переменных и соответствующие действия. То есть, сам инпут все еще невидим и не может получить фокус.

Чтобы заработало, нужно ставить фокус позже, после цикла проверки, с помощью метода nextTick() вот так:

editTitleMode: function (item) {
    this.$set(item, 'edit_mode', true);
    this.$nextTick(() => {
        this.$refs['input_item_' + item.id][0].focus();
    });
}

В качестве бонуса — поставим курсор в конец текста в инпуте так, чтобы его (курсор) было видно:

editTitleMode: function (item) {
    this.$set(item, 'edit_mode', true);
    this.$nextTick(() => {
        let element = this.$refs['input_item_' + item.id][0];
        let position = element.value.length;
        element.focus();
        if (element.setSelectionRange) {
            element.setSelectionRange(position, position);
        } else if (element.createTextRange) {
            let range = element.createTextRange();
            range.collapse(true);
            range.moveEnd('character', position);
            range.moveStart('character', position);
            range.select();
        }
    });
}

Начиная с версии 5.5 в Laravel появилась функция-хелпер optional(). По сути — это лаконичная замена более громоздким и часто используемым проверкам if (isset(…)). Например, у нас есть объект $order, и мы хотим применить к нему некий шаблон, но только если он есть у пользователя-владельца. Обычно мы пишем как-то так:

if (isset($order->user->template)) {
    $order->user->template->apply($order);
}

С хелпером optional() мы напишем короче:

optional($order->user->template)->apply($order);

Если $order->user, или $order->user->template не существует, вызванный метод просто вернет NULL и ошибки не будет.

Хотя хелпер довольно удобный, сколько ни пользуюсь/встречаю его где-то, каждый раз непривычно выглядит. В связи с чем никак не определюсь — надо им пользоваться, или привычный if (isset()) читабельнее.

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

Допустим, мы хотим принять массив с переменным количеством элементов, а в каждом элементе чтобы были поля id и weight. Вот так:

[
  'items' => [
    ['id' => 1, 'weight' => 5],
    ['id' => 5, 'weight' => 4],
    ['id' => 7, 'weight' => 3],
    ['id' => 8, 'weight' => 2],
    ['id' => 9, 'weight' => 1],
    // ...
  ],
]

Тогда нам нужно, чтобы поле items в запросе — присутствовало и было массивом, а значения id и weight — присутствовали и были целыми числами. Валидируется это так:

$data = $request->validate([
    'items' => 'array|required',
    'items.*.id' => 'integer|required',
    'items.*.weight' => 'integer|required',
]);

Таким образом будет отсечено все кроме поля items, в котором во всех элементах останутся только поля id и weight. Если по какому-то из значений вложенных элементов будут ошибки, то в errors они попадут с ключами items.i.id и items.i.weight, где i — индекс элемента в массиве items.

На днях совершил над собой титаническое усилие и добавил-таки своему Netspark.ru английскую версию. Учитывая, что это по сути одностраничник (ну, плюс 404 и «Сайт на обслуживании») — можно было бы тупо скопировать и поменять текстики на английские. Тем более английскую версию поставил на другой домен. Но все же чтобы фронт-энд был одинаковый в обеих версиях — мало ли там, добавить чего, поменять — решил использовать возможности локализации. О чем и расскажу немного.

Локализация в OctoberCMS — примерно такая же, как в Laravel. Есть файлы с локализацией, например lang.php, из них возвращаются массивы, примерно так:

return [
    'messages' => [
        'my_message' => 'Hello world',
    ],
];

После чего используется фильтр trans в твиге, где обращение к строке происходит как author.pluginname::lang.messages.mymessage. Author и pluginname — это имя автора и плагина, чтобы было ясно, откуда брать строки. Соответственно, файлы локализации должны жить в плагинах.

Это нормально, если проект не совсем примитивный и в нём есть кастомный плагин для всяких там дополнений и расширений. Но в рассматриваемом случае проект совсем примитивный и кастомных плагинов в нём нет, соответственно, хранить переводные строки негде. В таком случае нужно использовать плагин Translate. Если он установлен, хранить переводы можно прямо в theme.yaml используемой фронт-энд-темы. Заинклудить отдельный ямл с переводами тоже можно, да.

В файле строки будут храниться вот так:

translate:
    en:
        nav.portfolio: 'Our works'
        nav.services: 'Services'
    ru:
        nav.portfolio: 'Наши работы'
        nav.services: 'Услуги'

А обращаться к строчкам во фронт-энде можно с помощью фильтра твига _, вот так:

{{ 'nav.portfolio'|_ }}

То есть даже неймспейс никакой соблюдать не надо.

В фильтр перевода можно передавать параметры для подстановки:

{{ 'There are :works works in portfolio'|_({works: 1000}) }}

Естественно, строчку There are :works works in portfolio тоже можно положить в ямл и заменить дескриптором.

Помимо фильтра перевода _, есть и фильтр __, вызывающий transchoice() и помогающий в правильном склонении множественных чисел.

Чтобы строки из yaml-файла попали в систему, нужно их сначала обнаружить плагином Translate. Для этого со страницы переводов нужно запустить сканирование сообщений и затем почистить кэш.

К слову, если пользоваться плагином Translate, хранить строки в yaml-файле вообще необязательно. Если подать любую строку во фронт-энде на фильтр перевода, она может быть отсканирована и переведена через админку плагина. Примерно как функция t() в Друпале — засунул в неё что-нибудь, и это что-нибудь стало можно перевести. Но что еще интересно, в отличие от Друпала, где системный язык всегда английский и мы переводим с него, в OctoberCMS с плагином Translate дефолтный язык — действительно дефолтный. То есть мы можем сделать сайт на русском, сделать русский дефолтным, и переводить строки с русского на французский, или китайский, вообще без какого-либо упоминания английского.

Что еще можно сказать. Как видно из скриншота выше, плагин позволяет экспортировать переводы в и импортировать из csv-файлов (аналогично импорту-экспорту моделей).

Напоследок приведу пример определения текущей локали в системе. Я просто добавил обработчик onStart() в лейаут, и страницам, использующим этот лейаут, стали доступны переменные switchLocaleName, switchLocaleFlag и switchLocaleLink.

use RainLab\Translate\Classes\Translator;
protected $translator;

function onStart() {
    $this->translator = Translator::instance();
    $switchLocale = ($this->translator->getLocale() == 'ru') ? 'en' : 'ru';
    $this['switchLocaleName'] = ($switchLocale == 'ru') ? 'Русская версия' : 'English version';
    $this['switchLocaleFlag'] = 'assets/img/flags/' . $switchLocale . '.svg';
    $this['switchLocaleLink'] = ($switchLocale == 'ru') ? 'https://netspark.ru' : 'https://netspark.pro';
}

Лично мне это пригодилось, чтобы построить свой переключатель языков, который направляет на другой домен, вместо изменения языка в URL.

Есть в Drupal такой модуль, S3FS, создает стрим-враппер s3:// для работы с файловыми бакетами на Amazon S3. Модуль в принципе удобный и работает, но вот только не все файловые функции умеют в такой стрим. Например, если мы хотим проверить, существует ли в бакете файл, то file_exists('s3://myfile.txt') всегда вернёт FALSE.

Если заглянуть в код класса S3fsStreamWrapper, то там для проверки используется $this->s3->doesObjectExist(). Можно было бы сделать красиво, вот так:

file_stream_wrapper_get_instance_by_scheme('s3')
  ->s3
  ->doesObjectExists('my-bucket', 'myfile.txt');

Только вот незадача: $this->s3 — клиент S3 Aws\S3\S3Client, вокруг которого работает стрим-враппер — это protected-свойство.

Пришлось ковыряться и делать некрасиво:

$config = _s3fs_get_config();
$s3 = _s3fs_get_amazons3_client($config);
$s3->doesObjectExist('my-s3-bucket', $filename);

То есть вытягивать конфиги, создавать клиент вручную, и тогда уже проверять.

А мораль такая. Если вы пишете враппер вокруг какого-нибудь сервиса, и решили сделать свойство, содержащее объект сервиса, недоступным снаружи — подумайте. Может хоть геттер добавить стоит, если уж не реализуете обертку над каждым полезным методом?

Как я уже упоминал, в коробке Drupal 8 есть такой полезный модуль Content Moderation. Он позволяет модерировать материалы на базе редакций (revisions): материал может быть в состоянии (moderation_state) черновик, опубликован, или в архиве. Названия состояний можно менять, можно добавлять и новые состояния, и переходы между ними. При каждой смене состояния материала создается новая редакция. Благодаря этому можно, например, оставить проверенную редакцию опубликованной для всех пользователей сайта и, в то же время, работать с более новой редакцией в состоянии черновика.

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