В этой статье содержится небольшой обзор книги “Design Patterns for Vue.js: A Test Driven Approach to Maintainable Applications”, которую написал автор Lachlan Miller. Найти ее можно, например, на gumroad.com. Полный код примеров книги – в github репозитории автора книги.
Эта книга о шаблонах проектирования (паттернах) и тестировании Vue-приложения. Автор призывает первым делом задумываться о том какие шаблоны проектирования сделают будущее приложение максимально гибким, как сделать код максимально тестируемым. Паттерны сами по себе являются независящими от фреймворка. Это фундаментальные концепции. Но автор демонстрирует типичные ситуации для Vue-приложения, в которых тот или иной шаблон работает. Он показывает как может выглядеть их применение.
Содержание обзора
- Чего ждать от книги
- Компонент как чистая функция
- Отделение бизнес логики
- Тестирование кода с запросами к API
- Неотображаемные компоненты
- Шаблонные функции
- Dependency Injection с provide и inject
- Паттерн Стратегия
- Выносим код в Composables
- Еще раз про разделение кода
- Резюме
Чего ждать от книги
Каждая глава книги описывает какую-то конкретную идею и может читаться независимо от других глав. Книгу можно использовать как справочник и время от времени возвращаться к нужному месту.
Автор книги пишет: “Хорошие разработчики сосредотачиваются на инструментах и фреймворках, а великие разработчики сосредотачиваются на структурах данных и их взаимодействии друг с другом, тестируемости и легкости поддержки”.
Вся книга как раз и посвящена тому, чтобы настроить образ мышления программиста должным образом.
Компонент как чистая функция
Первые практические примеры в книге рассматривают Vue-компонент как функцию. У компонента есть свойства, так же как у функции есть параметры. Если компонент создает одну и ту же разметку при тех же значениях свойств, то такой компонент похож на чистую функцию. У него нет побочных действий (side effects). Такой компонент проще тестировать.
Автор книги показывает, что если разделять код с побочными эффектами (например обращениями к API) от кода, который можно представить как чистую функцию, то такое приложение выиграет в простоте покрытия тестами.
Отделение бизнес логики
Следующая мысль автора книги. Бизнес логику необходимо отделять от кода, который занимается отображением. Это тоже благоприятно сказывается на тестируемости и поддерживаемости кода. Если у нас есть такое разделение, то для смены UI фреймворка не понадобится переписывать код бизнес логики.
Тестирование кода с запросами к API
Логическим продолжением темы разделения кода служит глава про тестировании кода, который связан с запросами к API сервера. Предлагается использовать Mock Service Worker (MSW). Этот инструмент представляет собой имитацию сервера. Так мы не делаем mock-заглушек для функций, которые обращаются к API. При таких тестах фактически происходят реальные http-обращения, но к фейковому серверу. А значит приложение тестируется в максимально близкой к реальной среде.
Похожего же подхода можно достичь при использовании Cypress intercept. Если для тестирования используется Cypress, то проще выбрать этот способ. Однако MSW может работать и в браузере, что может оказаться полезным при отладке.
Неотображаемные компоненты
В этой главе рассказывается как с помощью слотов переиспользовать в компонентах часть методов решающих общую задачу.
Создается неотображаемый компонент (Renderless Component) со слотом. У компонента есть свойства. В эти свойства родительский элемент, который использует неотображаемый, будет передавать входящие данные. А тот в свою очередь будет результаты работы методов передавать через параметры слота. Это интересный подход.
Шаблонные функции
В этой главе говорится о случаях, в которых вместо шаблона выгоднее использовать шаблонные (render) функции. Когда шаблон компонента формируется в js-функции, а не разметке, то в распоряжении разработчика гораздо более мощный инструмент. Хотя в этом случае и приходится пожертвовать наглядностью, мы получаем большую гибкость.
Dependency Injection с provide и inject
Далее немного рассказывается как с помощью provide и inject можно давать доступ к общим данным для дерева компонентов. Чтобы не “прибивать гвоздями” к этим вещам свои компоненты используется Composable обертка useStore().
Паттерн Стратегия
В ряде случаев в свойства компонента полезно передать функции, описывающие какой алгоритм работы использовать. Это делает компоненты более универсальными. В них не содержится способа выполнения какой-либо задачи. Если задачу можно выполнить несколькими способами, то алгоритм выполнения мы можем передать компоненту. Этому посвящена очередная глава книги.
Выносим код в Composables
Далее описывается подход выноса неких связанных данных и методов в Composable функции вида useXXX и использование таких функций в компонентах. Этот подход в Compostion API пришел а смену миксинам, которые имеют свои недостатки.
Еще раз про разделение кода
В последней главе рассказывается еще раз об отделении бизнес логики от интерфейса. Необходимо стараться выделить бизнес логику в чистые функции и тестировать ее там. В то время как интерфейс должен быть нацелен на отображение информации и взаимодействие с пользователем.
Держа бизнес-логику в чистых функциях мы легче сможем ее протестировать в различных ситуациях. В то время как интерфейс будет иметь свои тесты нацеленные на отображение и реакцию на события.
Если же не разделять бизнес-логику и интерфейс, то придется все случаи для бизнес логики прогонять также и через интерфейс.
Резюме
Если вы web-разработчик с опытом, то с содержанием данной книги стоит ознакомиться поближе. Автор глубоко осмысливает проблемы Vue-разработки и подходы к их решению. После прочтения, скорее всего, ряд практик вы возьмете на вооружение. Ваш код начнет меняться в лучшую сторону.