Как и зачем мы сделали студийный пет-проект — конструктор смет Powerlay

Привет! С вами Алена, тимлид звена фронтенд-разработки в Landau. Рассказываю, как в процессе обучения фронтендеров мы придумали студийный пет-проект Powerlay и упростили работу отдела продаж.

Наш подход: каждому сотруднику — свой пет-проект

Мы в агентстве уже несколько лет за каждым сотрудником закрепляем личную задачу на обучение: менеджеры повышают насмотренность, дизайнеры изучают новые инструменты. У фронтендеров такая задача тоже есть — специально для них мы придумали проект конструктора смет Powerlay. Дело в том, что нам при работе с клиентами часто приходится рассчитывать сметы и готовить коммерческие предложения — это рутина процесса продажи, от неё не избавиться. В текущем составе мы работаем уже 6 лет и за это время попробовали Google Docs, Excel и Figma. При очевидных плюсах этих решений, минусов тоже хватает, так что мы подумали, а не сделать ли конструктор для быстрой сборки?

"Творите!": в чем ценность проекта

Дизайнеры для ускорения работы с проектом используют готовые дизайн-системы. Мы совместно выбрали систему от компании Atlassian (Jira, Confuence): в ней привлек набор компонентов и готовые реализации.

Решили писать на VUE, потому что никто из команды на момент старта проекта на нем писать не умел. Я его как раз тогда начала учить. В этом суть пет-проектов — разбираться в том, что ты еще не умеешь делать.

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

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

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

Мы сами удивились: несколько регистраций на уровне MVP

Сейчас мы собрали наш проект до уровня MVP, на это ушло полгода и два рефакторинга. Занятно, что рефакторинг делают те же разработчики, что писали первые реализации сервиса, то есть они видят, как выросли за последний год-два.

Удивительно: мы выложили страницу авторизации в сеть и через некоторое время получили несколько регистраций. Без какой-либо рекламы люди начали пользоваться сервисом. Забавно, но мы узнали об этом, когда получили тревожное письмо: слетел SSL-сертификат.

Архитектура проекта

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

Для реализации drag-n-drop использовали vuedraggable. Остальные пакеты всем известны.

Правило хорошего тона — явно описывать, где и что лежит на проекте в Readme. Пригодится не только джунам, но и уже опытным разработчикам. Подробно расписываем структуру проекта, что содержат и за что отвечают конкретные файлы проекта.

Список библиотек

На скриншоте — список библиотек, которые используем на проекте. Ничего экстраординарного, как раз подходит для освоения фреймворка. Так как пакеты постоянно обновляются, важно следить за версионностью, чтобы не было проблем со сборкой. Ссылки на pug и SCSS тоже поставим =)

Структура проекта на старте слева и текущая структура — справа.

На скриншоте слева — классическая структура проекта Vue. Это состояние на старте проекта.

Расскажем подробнее, что тут есть: папка html – стандартная папка статичных файлов, переименуем ее потом в public. В browserlistsrc прописываем нашу политику поддержки браузеров, обычно оставляем две последние стабильные версии. Babel – для настройки компиляции скриптов, чтобы все везде запускалось.

На скриншоте справа — текущая структура проекта. Из заметных изменений: выделили взаимодействие с api в отдельную директорию, добавили страницы приложения в директории pages. Разбили большие компоненты на более мелкие.

Как работали с библиотекой Атлассиан

Мы обошлись UI-компонентами, которые уже были реализованы. При этом не все паттерны взаимодействия с интерфейсом соблюдали, кое-где нарушали гайд. Плюс у нас в проекте есть drag-n-drop — этот формат работы с контентом в рамках дизайн системы не сильно развит.

Сейчас уже понятно, что крупные проекты с составным UI-компонентами и UX-паттернами на дизайн-системе Atlassian ….. (она довольно скупая)

Интерфейс создания самой сметы из заранее подготовленных блоков-строк.

В Powerlay есть возможность менять данные в строке и добавлять новые. Кнопки быстрых действий со строкой сделали не по канону Jira — нам показалось так удобнее. Работа со сметой — самая сложная часть реализации драг-н-дропа, но и самая интересная.

Зачем перешли с HTML на PUG

Переход с html на pug можно назвать не самым дальновидным решением. Мы реализовали его, чтобы обкатать вариант нашей стартовой сборки фронта уже для коммерческих проектов. Замечу, что у самого Vue есть шаблонизатор и для целей пет-проекта его бы хватило.

На примере небольшого фрагмента интерфейса посмотрим, что получилось.

Итак, у нас есть список рейтов. По сути, интерфейс представляет собой таблицу и одну небольшую форму из двух инпутов и кнопки.

Вот как выглядела html-разметка этой части интерфейса: довольно многословная. В итоге решили перейти на PUG.

После переписывания PUG разметка выглядит так.

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

Взаимодействие с бэкендом

Этот проект для джуна — отличный пример взаимодействия с бэком. Бэкендеры подготовили документацию по работе с API в свагере — все как на взрослых коммерческих проектах.

Ниже — часть из методов работы с API: авторизация, регистрация, в том числе через социальные сети, сброс пароля. В разделе Catalogue – методы для работы со сметой: добавление, изменение и удаление.

На скриншоте видно, как реализована регистрация с последующей автоматической авторизацией. Посылаем запрос через промисы на /auth/login , куда передаем данные пользователя — email и пароль. В случае успеха — логинимся в интерфейсе, в случае ошибки — разлогиниваемся.

А здесь — реализация запроса по принципу DRY. Она универсальная, остается только применить нужные переменные, url, метод и другие параметры. Видно, что для работы с запросами выбрали Axios. Эта библиотека проще в понимании, чем стандартный метод fetch. Кстати, Axios входит в программу многих онлайн-школ программирования.

А вот как применяется универсальный метод request для получения (getCatalogues), добавления (addCatalogues) и других операций со сметами. Просто подставляем нужные значения вместо переменных, которые берем из документации от бэкенда.

Что будет дальше

Сейчас мы тестируем идеи и доделываем сервис: функционально работает только MVP. В дальнейшем планируем проработать профиль пользователя и добавить шлюз оплаты.

С точки зрения кода самый важный пункт — переход на TypeScript. В коммерческих проектах это давно стандарт, а до пет-проекта у нас пока руки не доходят. Одновременно хотим зарефакторить неоптимальные решения. В общем, учиться, учиться и еще раз учиться.

Бонус

Мы сделали конструктор смет Powerlay бесплатным. Регистрируйтесь и пользуйтесь! Будем рады любой обратной связи, комментариям и предложениям.