На днях начал работу над новым проектом, и выдался хороший случай попробовать Livewire и Volt с ним, с последней версией Laravel. Про Livewire в последних версиях Ларавела я раньше слышал и читал, но руки как-то не доходили. А теперь дошли и сейчас мы познакомимся с ним поближе.

Что такое Livewire

Что вообще такое Livewire? Это фреймворк, позволяющий разрабатывать динамичные интерфейсы прямо на PHP. Как гласит главная страница фреймворка:

Powerful, dynamic, front-end UIs without leaving PHP.

То есть «мощные, динамичные фронт-энд интерфейсы, не покидая PHP». Ничего не понятно, но очень интересно. Ну, я немного разобрался (прочитал документацию!) Этот фреймворк позволяет нам, путём вставки специальных директив типа wire:model.live="filter" прямо в blade-шаблон, в html какого-нибудь инпута, сделать этот инпут динамическим. Или, как раньше говорили, его аяксифицировать.

То есть заставить элемент отправлять запросы на сервер без перезагрузки страницы и обновлять соответствующий view по данным в ответе на запрос

И это — без необходимости писать JavaScript-код, вообще. И хотя мы в примере ниже немного JS-кода напишем, это, строго говоря, действительно необязательно.

Когда мы пишеем тесты на бэкенд-путь, который возвращает данные с отношениями, ($order, в нём $order→user, в нём $order→user→plan и т.д.) — следует избегать проверять отсутсвие тех или иных id через assertJsonMissing(['id' => $order2->id]) и ему подобные методы. Когда тестов окажется много, и мы их запустим разом, инкремент-айдишники в таблицах побегут и в какой-то момент внутри $order, который в json есть, внезапно окажется $user у которого id такой же как у $order2, и тест не пройдет.

Имеется в виду запуск всего пакета тестов, например, в Laravel с включенным трейтом RefreshDatabase: таблицы БД после каждого теста чистятся, но структура заново не пересоздается. Это и быстрее, и более похоже на «живую» среду.

И мы будем голову ломать, почему вдруг этот тест сломался на ровном месте и почему это проявляется, только если сразу все тесты запустить. И ладно мы, мы-то быстро найдем почему. А вот если мы работаем с ИИ, он половину рабочего кода искромсает своми правками, пока допрёт, что это было. Если допрёт вообще — мой вот не допёр.

В общем, проверять json ответа без декодирования в массивы/объекты не очень хорошо, т.к. может повлечь подобные ложные мэтчи.

Неправильно:

  $response->assertJsonMissing(['id' => $order2->id]);

Этот код будет искать по содержимому всего json и рано или поздно найдет вложенную зависимость со случайно совпавшим id.

Правильнее будет например:

  $data = $response->decodeResponseJson('data');
  $this->assertNotContains($order2->id, array_map(function ($order) {
    return $order['id'];
  }, $data););
  // так мы явно показываем, на каком уровне вложенности тестируем
  // также можно использовать замыкания внутри assertJson(), позволяющие ходить по уровням структуры документа

Недавно писал, что очень неплохо получается с помощью ИИ делать юнит- и фича-тесты. А в этой заметке решил разобрать подробнее, на примере, как это выглядит.

Для определенности уточню, что использую я плагин Codeium для Visual Studio Code под Linux, тариф бесплатный. Никаких дополнительных настроек не применял, на сайте указано что плагином используются Chat GPT, Claude, DeepSeek и Gemini. Проект, с которым я работаю, написан на Laravel, в нём есть такая функция — на определенный route можно отправить post-запрос с сообщением, и это сообщение будет отправлено телеграм-ботом в соотвествующий чат.

Эта функция уже написана, на неё есть тесты, и она работает. А в данном примере мы создадим feature-тест, проверяющий ограничение на количество сообщений в день в соответствии с тарифным планом пользователя. Такого функционала в проекте еще нет, я его хочу создать в соответствии с методикой TDD. То есть сначала написав тест, а затем последовательно запуская его и исправляя появившиеся ошибки.

Вот для написания данного feature-теста я и применю ИИ. Открываем подходящий для теста файл, жмём Ctrl+I. Чат жопотэ, поехали!

В Ларавеле можно из отношения «один ко многим» сделать отношение «один к одному». Например, у нас есть модель Monitor, у которой может быть много дочерних моделей MonitorCheck:

class Monitor extends Model
{
    /**
     * Monitor can have many checks
     * @return \Illuminate\Database\Eloquent\Relations\HasMany
     */
    public function checks() {
        return $this->hasMany(MonitorCheck::class);
    }

}

тогда мы можем объявить отношение для получения последней модели MonitorCheck так:

    /**
     * Monitor has a last check
     * @return \Illuminate\Database\Eloquent\Relations\HasOne
     */
    public function lastCheck() {
        return $this->checks()->one()->latestOfMany();
    }

Однако если мы захотим объявить отношение для последней модели с условием, так сделать не получится. Допустим, мы хотим последнюю модель MonitorCheck с проваленным тестом.

public function lastFailedCheck() {
    return $this->checks()->where('passed', '=', FALSE)->one()->latestOfMany();
}

Такой вариант не сработает, будет возвращать null. Причем, если убрать latestOfMany(), то отношение будет работать и вернет MonitorCheck с проваленным тестом, только не последний. А с latestOfMany() не будет работать, запрос будет составляться неправильно (точнее, не так, как мы хотели бы).

А правильно объявлять данное отношение так:

public function lastFailedCheck() {
    return $this->hasOne(MonitorCheck::class)->OfMany(
        ['id' => 'max'], 
        function (Builder $query) {
            $query->>where('passed', '=', FALSE);
        }
    );
}

Вместо id в ['id' => 'max'] можно использовать и другие поля, например, created_at, главное условие аггрегации описать.

Время от времени бывает необходимо организовать файловое хранилище за пределами /public. Например, для того, чтобы контролировать доступ к файлам (недоступным по прямой ссылке) по неким правилам.

Сходу из коробки в Laravel 6 такая фича на 100% не предусмотрена, но сделать её руками достаточно нетрудно.

Для начала разобьем задачу на части. Нам нужно:

1. Определить, где будут храниться файлы (private storage).
2. Прикреплять файлы к некой модели, чтобы на основе этой модели управлять доступом.
3. Обеспечить сохранение файлов в private storage.
4. Реализовать, собственно, контроль доступа и выдачу файлов по некоему пути.
5. На закуску добавим автоматическую генерацию миниатюр.

Далее мы разработаем приватное файловое хранилище с управлением файлами с помощью библиотеки spatie/laravel-medialibrary.

В первой части статьи мы строили бэкенд на Laravel для вывода разнородных событий на календаре. В этой части мы рассмотрим построение фронт-энда на Vue.js с помощью FullCalendar, для которого есть интеграция fullcalendar-vue. Получится примерно как на картинке.

Что вообще должен делать наш фронт-энд?

Во-первых, загружать из бэк-энда события по созданному ранее пути /api/calendar.

Во-вторых, отображать эти события в соответствии с установленными для них датами.

В третьих, как-то визуально отличать одно событие от другого, чтобы было нагляднее.

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

Будем считать эти четыре пункта нашим ТЗ на фронт-энд и приступим к реализации.

Вчера запланированно вышел Laravel 6! Для тех, кто не хочет, или не умеет в английский, пересказываю вкратце, чего там нового.

Во-первых, с этого момента нумерация версий Ларавел будут соответствовать правилам SemVer: MAJOR.MINOR.PATCH. То есть, если кто не знает, MAJOR — серьезные изменения, нарушающие обратную совместимость, MINOR — изменения, ничего не ломающие и PATCH — правки и фиксы, не привносящие нового. Наверно, это хорошо, хотя лично мне и так было нормально.

Во-вторых, Laravel 6.0 — это LTS-версия, то есть версия, которая будет поддерживаться долго. Долго — это, в данном случае, два года фиксов ошибок и три года фиксов уязвимостей.

Другие новшества:

• улучшена возможность контроля ситуации, когда доступ к функции у юзера есть/нет (например, для вывода сообщений);
• в классы асинхронных заданий (Jobs) добавлена поддержка Middleware;
• добавлены ленивые коллекции (LazyCollections), позволяющие работать с большими объемами данных как с обычными коллекциями Ларавела. Почитайте док по ссылке, это интересно;
• улучшена генерация подзапросов в Eloquent;
• генератор фронтэнда (например, на Vue.js) вынесен в отдельный пакет laravel/ui.

Как обычно, есть Upgrade Guide — руководство по апгрейду до последней версии. В руководстве утверждается, что, если вы держали руку на пульсе и у вас последний Laravel 5.8 — управитесь с обновлением примерно за час. Не забудьте запустить тесты!

А я, как руки дойдут, проверю и отпишусь.

В данной заметке из трёх частей рассматривается построение календаря, отображающего события, связанные с разнородными сущностями системы. Бэк-энд реализован на Laravel, фронт — на Vue.js. Календарь сделаем с помощью Full Calendar и соответствующей интеграции fullcalendar-vue.

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

В результате получится примерно вот так:

Некоторое время назад обнаружил статью, где показывалось, что трейт RefreshDatabase в тестах позволяет им (тестам) работать с MySQL быстрее, чем с Sqlite в режиме memory. Это выглядело странно и почти немыслимо, но оказалось, что, действительно, так и есть. Перевёл в нескольких проектах юнит-тесты с Sqlite на MySQL, заменил трейт с DatabaseMigrations на RefreshDatabase, и полный пакет тестов стал выполняться в среднем на ~30% быстрее (плюс большая совместимость с реальной средой достигается).

Работает оно быстрее — потому что трейт позволяет не поднимать все миграции заново в каждом тесте, а просто очищать уже созданные один раз таблицы. Но у этого достоинства есть, конечно, и логическое продолжение. Очевидный недостаток в том, что один раз создать эти таблицы всё же нужно. И это будет точно медленнее, чем в sqlite.

Соответственно, если ты практикуешь TDD, то в ходе разработки гораздо чаще запускаешь не полный пакет юнит-тестов, а какой-то один тест, верифицирующий тот кусок функционала, над которым, собственно, ты работаешь. И тут, за счет скорости развертывания миграций, MySQL очень сильно проигрывает.

Решить эту проблему, однако, очень просто. Нужно в «режиме TDD», то есть при запуске отдельного теста, использовать другой конфиг. В котором вместо MySQL подставлен sqlite:

<env name="DB_CONNECTION" value="sqlite"/>
<env name="DB_DATABASE" value=":memory:"/>

И запускать тест так:

phpunit -c phpunit_sqlite.xml <путь к тесту>

А чтобы не обламываться, что приходится каждый раз набирать ключик и путь к конфигу, нужно заменить эту команду простеньким синонимом:

alias tdd="phpunit -c phpunit_sqlite.xml"

Понятно, работать будет не для всех случаев. Например, если какой-нибудь из пакетов (spatie/laravel-tags, скажем) использует нативную поддержку JSON в MySQL, тесты этого функционала в sqlite работать вообще не будут. Но в целом этот трюк на длинной дистанции (особенно, с не очень быстрым компьютером) сэкономит прилично времени.

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

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

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

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

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

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

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