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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#смета `#дизайнсистемы #сервисы #обучение_программированию