Мой опыт работы с необычным подходом к построению группы React приложений

• Вступление

• О системе

• Плюсы и минусы

• Возможные улучшения

• Заключение

Вступление

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

В данной статье постараюсь рассказать об одной из систем построенной на React и TS с которой удалось поработать, субъективно описать ее плюсы и минусы, а так же затронуть тему того, что можно было улучшить в рамках системы.

Если у тебя есть какие то замечания (или находишь статью душноватой), дополнения или можно как то написать статью лучше, то пожалуйста напиши об этом в комментарии, мне будет очень интересно почитать 🙂

---

Немного боли из проекта:

• Полное копирование всей директории с исходниками => Вставка директории и ручное удаление ненужных частей

• Практически полное отсутствие переиспользуемых компонентов

• Глобальные файлы со стилями без использования модульности или CSS-in-JS

• Написание стилей через id и теги

• Нам нужны новые фичи, а это не принесет денег бизнесу (с)

  • У нас тут все логично, поразбирайся немного и поймешь что все логично и правильно

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

---

О системе

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

1. Подготовка небольших фрагментов кода для вставки в мобильное приложение через WebView

2. Проведение AB тестирования для увеличения конверсии продукта (то есть если люди не стали больше покупать услуги, директория с фичей удаляется или уходит в папку deprecated)

Данная система имеет 2 типа приложений Screens и Widgets, главное их различие в том, куда WebView позже их вставит в мобильное приложение и наверное это все 🙂

Screens и Widgets это набор директорий, где каждая собирается Webpack как отдельное React приложение, так же приложение имеет свой конфиг и конфиг в директории фикстур.

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

Ключевая структура корня приложения имеет примерно следующий вид:

{   .storybook: "Конфиги для общей настройки сторибука",   node_modules: "Куда же без них",   scripts: "Общие скрипты с функциями",      src: {   js: {   fuxtures: "Конфиги для тестирования", components: "Буквально пару переиспользуемых компонентов",   screens: "Директория с приложениями",   widgets: "Другая директория с приложениями" }, img: "Общие стили", styles: "Директория с общими стилями", index.html: "Корневой html шаблон для приложений" }  // И некие стандартные вещи вроде tsconfig.json, package.json, jest.config.js, postcss.config.js, webpack.common.js ... }

Структура экрана или виджета следующая:

{ components: "Компоненты под текущий экран или виджет",   colorThemeStylesheet.tsx: `   Файл в котором через react-helmet устанавливаются css переменные,     значение которых берется из конфига или конфига фикстуры если      он имеется.   `,   config.ts: "Локальный конфиг экрана",   id999.pcss: "Стили для экрана или виджета, где 999 это id текущего экрана",   id999.stories.ts: "Конфиг для storybook",   index.ts: "Входной файл для сборки вебпака",   Screen.tsx: `   JSX код в основном в нем содержится весь код,      который в редких моментах вынесен в локальные компоненты   ` }

Принцип создания нового экрана

Берем директорию с похожим функционалом делаем CTR+C => CTR+V, добавляем щепотку магии фикстурного конфига и вуаля! Вроде как наше промо готово, но нам же нужно сделать не 100% копию другого экрана, а с отличиями, мы их делаем для экспериментов и вооот тут начинается унылый механический ад.

Предположим у нас в экране который мы копировали есть следующий функционал:

• название

• слайдер

• описание

• продукты

• Кнопка покупки

А по ТЗ нужно:

• название

• слайдер

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

• описание акции

• продукты

• Кнопка покупки

---

Начинаем идти по кругам рутины

Для начала мы должны удалить вручную из Screen.tsx всю JSX разметку слайдера и разметку «описания акции» =>

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

Переходим в ColorThemeStylesheet.tsx и убираем места св-ва конфига которые не используются =>

Убираем с нашего config.ts лишние параметры и интерфейсы с типами =>

Идем в фикстуры, повторяем процесс =>

Переименовываем директорию на новые экран =>

Переименовываем файл стилей и сторибука =>

В файле стилей оборачиваем в наш id экрана для инкапсуляции стилей для сторибука (тк в сторибуке отображаются все экраны и виджеты и если не делать вышеперечисленное, то сторибук может поплыть) =>

Идем в 100 экран ищем JSX разметку анимации «моргания глаз», вставляем ее, вставляем стили к ней, вставляем ColorThemeStylesheet какие-нибудь св-ва конфига и фикстур (предварительно дописав типы в конфиге и сами значения), вставляем и понимаем что в 100 она была реализована криво или с отличающимся сильно разным функционалом =>

Ломаем клавиатуру об стену => достаем из ящика новую

Повторяем процесс удаления анимации =>

Берем из 102, повторяем процесс вставки руками

Ищем «акции» или верстаем этот блок сами (чтобы потом его удалить в дочернем экране)

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

---

Плюсы и минусы

---

Возможные улучшения

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

   P.S. так как наша система должна быть максимально гибкой мы должны использовать композицию элементов и если есть необходимость в изменении компонента использовать Theme, но не менять нашу компоненту Modal, тк это может затронуть другие экраны.

   

2. Создание некого шаблона который будет собирать в пустой экран или виджет (а в нем использовать импорт компонентов из 1 пункта)

---

Заключение

Тк обладаю неким своим контекстом знания о системе, мог что то упустить в статье что привело бы к ее непониманию, однако очень надеюсь что все было понятно и интересно 🙂

Мне кажется улучшения описанные выше помогли бы очистить систему от вышеописанных минусов. А как вы думаете что можно сделать в данной системе чтобы упростить процесс создания новых экранов и виджетов?