Прикручивал тут к одному проекту на Drupal 8 Vue.js для фронт-энда. Нужно было несколько интерактивных фильтров на паре страниц сделать, на Vue ложилось идеально. Но поскольку кроме фильтров больше ни для чего Vue был не нужен, в полный headless не пошел. Ограничился эдаким headless-less подходом, когда на нужных страницах разметку генерирует все еще Друпал, а Vue берет с неё свои компоненты, данные в которых переданы через пропы, а незначащая разметка — через слоты.

Изначально хотел описать по порядку, что и как я делал, но по ходу применения этого гибридного headless-less варианта пришел к выводу, что делать так вообще не надо. Лучше (если Vue нужен только для конкретных страниц) — отдавать что-нибудь вроде

<master-component :data="jsonData"></master-component>

где в jsonData упаковано всё что нужно для генерации разметки на стороне Vue. А дальше пусть Vue сам разберется.

Потому что иначе постоянно возникают ограничения и несовместимости, возникают и выносят мозг. Перечислю некоторые из них.

Во-первых, часть разметки все равно придется перенести в компоненты. Вот например представим, что нам надо список товаров фильтровать с помощью формы из нескольких чекбоксов. Если попробовать вставить разметку формы в слот и передать через scope значения в v-model, связь получится односторонняя. Фильтр примет начальные значения из scope, но передавать изменения обратно в компонент — не будет. То есть полностью сохранить темплейт на стороне Друпала не получится.

Во-вторых, вот есть у Vue.js транзишны для анимации. Пользоваться удобно, enter/leave можно сделать за 5 минут просто обернув компонент в <transition></transition> и добавив три строчки CSS. Но есть в транзишнах вот такая клевая штука для списков. То есть анимация вставки/удаления элементов списка. Если мы генерируем разметку на стороне Друпала:

{% for product in products %}
  <product :data="{{ product_data }}">
    <div>Разметка товара</div>
  </product>
{% endfor %}

то list-транзишны работать не будут, нужно чтобы список был сгенерирован на стороне Vue.js через v-for. То есть, опять-таки, чем больше передадим во Vue.js в виде json-данных — тем лучше.

Далее, если эти компоненты product переданы через слот в родительский компонент Products, мы будем испытывать затруднения если захотим обратиться к каждому из дочерних product-ов (например, чтобы определить количество видимых в данных момент товаров). Так-то во Vue можно задать дочерним компонентам ref и обращаться в родительском через this.$refs. Но, опять же, для этого компоненты должны создаваться в родительском темплейте на стороне Vue. А так пришлось изгаляться с jQuery (что при наличии транзишнов не очень-то весело).

Наконец, следует помнить, что вся Vue-related разметка, сгенерированная на стороне Друпала, не проходит через систему сборки, в отличие от файлов .vue с компонентами. Из-за этого нужно быть осторожным в её написании. Например, взяли мы и деструктурировали для удобства данные, передаваемые в scoped-slot:

<div slot-scope="{ results }">
  <p v-show="results">There are results!</p>
</div>

И всё, пока-пока, IE11. А на стороне Vue этот код был бы собран с поддержкой совместимости.

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

Вдогонку к предыдущему посту — пара слов про создание фейковых дисков для тестов.

Как гласит документация, с помощью фасада Storage мы можем легко создать фейковый диск для тестов. Достаточно выполнить код:

Storage::fake($disk_name);

где $disk_name — название диска (если не указать, будет создан фейк для дефолтного диска).

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

Что еще следовало бы, на мой взгляд, подчеркнуть, так это то, что фейковый диск — это не какая-то виртуальная конструкция с набором поддельных методов. Это самый настоящий диск, то есть директория, которая появится в storage/framework/testing. Так что с помощью фейкового диска можно осуществлять (то есть тестировать) ровно то же самое, что с помощью обычного. Создавать файлы и директории, обрабатывать файлы с помощью сторонних библиотек (PHPWord, к примеру), удалять, копировать и даже возвращать на скачивание.

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

Допустим, у нас есть вот такой код (в контроллере, например для пути /documents/download):

return response()->download(
    $path, 
    'myfile.docx', 
    ['content-type' => 'application/msword']);

То есть выдача файла, находящегося в $path для скачивания под именем myfile.docx.

Протестировать, что файл отдается корректно, можно вот так:

use Tests\TestCase;

class DocServiceTest extends TestCase {

    /**
     * @test
     */
    public function user_can_download_document() {
        // обращаемся к пути, который отдает файл
        $result = $this->get('/documents/download');

        // проверяем http ok
        $result->assertStatus(200);

        // проверяем mime type
        $result->assertHeader('content-type', 'application/msword');

        // проверяем наличие аттача с заданным именем файла
        $result->assertHeader('content-disposition', 'attachment; filename="myfile.docx"');
    }
}

Рассмотрим такой юз-кейс. Есть вью с картой, есть экспозид-фильтр над ним, в который можно ввести адрес для фильтрации карты, и маркеры обновятся по ajax. Обычное дело.

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

Так-то экспозид-фильтры свои значения тоже в query кладут, но я ajax включил сразу и об этом забыл. Поэтому полез в hook_form_alter(). В голову приходит конечно, что #default_value у элемента надо поменять — и всё. Но оказывается, для экспозид-форм это не работает. Оказывается, у них дефолтные значения живут в другом месте и надо делать вот так:

function mymodule_form_alter(
  &$form,
  \Drupal\Core\Form\FormStateInterface $form_state,
  $form_id
) {
    // ...
    $form_state->setUserInput(['field_zip_postal_code_value' => $value_from_query]);
    // ...
}

Здесь field_zip_postal_code_value — это id фильтра.

А чтобы проверить, есть ли там уже какое-нибудь дефолтное значение:

$form_state->getUserInput()['field_zip_postal_code_value']

Говорят, этому нюансу сто лет в обед. Но сколько работаю — а вляпался в первый раз.

Не могу заставить себя писать front-end-тесты.

Как только вижу что-нибудь вроде

it('renders the correct message', () => {})

немедленно возникает ассоциация с

it('puts the lotion on its skin')

И не дает работать.

Сделать для того или иного материала теги — задача довольно типичная и распространенная. В этой заметке мы рассмотрим, как сделать модель тегируемой, а заодно — как реализовать автодополнение для этих тегов.

Для тегов в Laravel есть несколько пакетов (не с нуля же их писать), по описаниям мне подошел больше всего Spatie Laravel Tags. В нём работа с тегами реализована достаточно прозрачно и просто, плюс из коробки есть локализация для наименований тегов и slug-и для генерации страниц тегов.

Далее подробности.

Уже достаточно давно в свободное время штудирую курс Test Driven Laravel, посвященный, очевидно, применению методики TDD (Test-Driven Development) к разработке ПО на Ларавеле.

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

Вообще, видео-уроки я не очень-то люблю, но здесь формат совсем не раздражает (хотя текстовый вариант все равно был бы еще круче). Так что — рекомендую.

Что же касается самой методики TDD, мне кажется, у нас ей немного не повезло с локализацией названия. У нас это называется «Разработка через тестирование», то есть слово driven редуцировали до нашего «через».

А что такое вообще в данном контексте «через»? Можно прыгнуть через лужу, или можно кинуть через известно что. Эти варианты тут, видимо, не очень подходят. Можно выйти через окно, или даже войти через дверь. Это уже ближе, но все еще непонятно.

При беглом ознакомлении с таким локализованным определением, понятно одно. Сначала надо написать тест, а потом код под этот тест. Ну ок, любопытная методика. А вот есть еще одна: можно сначала написать код, а потом не писать тест. Тоже прикольно, а главное — гораздо быстрее.

Между тем, оригинальное слово driven в названии явно обозначает подконтрольность одного явления другому. То есть, в данном случае — что ход разработки полностью подконтролен тестам, тесты ведут разработку, направляют её, что из переводной версии не очевидно.

И пока не попробуешь что-нибудь сделать «через тесты» сам, не очень-то ясно, что в самой методике главное отнюдь не наличие тестов на весь код в финале. Это лишь сопутствующая плюшка, хотя конечно тоже важная. Главное заключается как раз в слове driven. В том, что написанный тобой же тест при каждом запуске говорит тебе:

• Ты хотел по этому урлу увидеть данные, а урла такого чо-то нету. Может, добавишь?
• Вижу урл, только почему-то данных не вижу. Надо что-нибудь вывести.
• Урл пытается вывести объекты, но не знает, где их взять. Давай табличку в БД создадим?

И так далее. То есть суть в том, что если грамотно (в форме теста) описать желаемый результат, то не нужно даже особо думать, что еще ты забыл сделать и почему не работает. Лог очередного запуска теста сам тебе расскажет — чего не хватает. На мой взгляд, если эту суть осознать, методика предстает совсем в другом свете, нежели «давайте потратим в два раза больше времени, чтобы у нас был вагон тестов на каждый чих».

Как-то так.

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

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

В процессе освоения и использования, набрёл на любопытный хак. Захотелось мне, значит, сделать множество полей с автодополнением, примерно так (упрощенно):

<ol>
    <li v-if="people" v-for="(person, index) in people">
        <autocomplete
            url="/people/search_by_name"
            anchor="name"
            label="email"
            :initValue="person.name"
            :onInput="autocompleteNameChanged"
            :onSelect="autocompleteGetData"></autocomplete>
        <button type="button" v-on:click="removePerson($event, index)" class="btn btn-default"><span class="fa fa-times"></span></button>
    </li>
</ol>

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

Но сначала небольшое отступление. Как известно, в Drupal 8 модуль Views включили в ядро и это прекрасно. Действительно, контриб, который автоматически ставят во все проекты, не должен оставаться просто контрибом. Но некоторые вещи, сопутствующие включению/порту на D8, несколько раздражают.

Подробности далее.

Работу с AJAX в OctoberCMS я уже раньше немного затрагивал, но для бэк-энда. А теперь можно затронуть и фронт. В этой заметке мы сделаем кнопочку Load More, чтобы подгружала без перезагрузки страницы новые посты блога (из плагина RainLab.Blog).

На первый взгляд может показаться, что для этого нужно влезть в компонент Posts этого плагина, но на самом деле — вовсе не нужно. Дело в том, что раньше из документации можно было подумать, что обработчики AJAX-событий нужно описывать только в классе контроллера (если в бэк-энде), или компонента (если во фронте). И поэтому не очень было понятно, как быть, когда ты хочешь получить красивый ajax-пейджер для блога. То ли лезть в код чужого плагина, что влечет проблемы с обновлениями. То ли писать свой собственный компонент, из которого грузить компонент Posts программно. Что ведет к сомнениям в том, надо ли вообще такой негибкой CMS пользоваться.