Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Со стартом активного импортозамещения еще несколько лет назад было трудно поверить, что оно сможет быть красивым, качественным и современным. Западные системы создавались и развивались много лет, а российское ПО создавалось с нуля, без такого обширного опыта (но, с другой стороны, и без легаси).
Меня зовут Андрей Комаров, я фронтенд-разработчик в ГК «КОРУС Консалтинг». Вот уже как несколько лет наша команда успешно внедряет систему отчетности для одного из крупнейших транспортных холдингов нашей страны на базе российского ПО LuxMS. В этой статье расскажу про опыт нашего проекта.
Немного предыстории
Наш проект – это система отчетности, с ежедневным обновлением данных, созданная на базе импортозамещающей технологии LuхMS BI. Система предназначена для разных групп пользователей, но ориентирована на топ-менеджемент заказчика. Географически она покрывает практически всю Россию.
Полностью готовая и работающая экосистема LuхMS BI позволила проводить полный цикл разработки системы отчетности: от экстракции данных до отображения их в виде различный форм визуализации. В отличие от аналогов, российская платформа дала быстро подстраивать визуальную часть под требования конкретного заказчика: достигается это путем фронтенд разработки в существующих визуальных сущностях BI-платформы – «дешах» (группах визуализаций).
Наследие разработки: дублирования, объемный импорт, устаревший API
Конечно, сейчас мы стремимся использовать только передовые технологии — но так было не всегда.
Изначально визуальная часть делалась на jQuery с использованием фреймов в одном деше, что рождало довольно большое количество проблем. Дублирование файлов, отсутствие «чистого» кода, большой объем файла для импорта, устаревший API и так далее. В целом было ясно, что jQuery не подходит для сложных пользовательских интерфейсов. Мы начали обсуждать рефакторинг.
Что для нас было важно:
Скорость работы. Мы обращали внимание на загрузку данных в приложение, на время отклика системы.
Повторное применение компонентов. Это сокращает время разработки.
Огромное сообщество. Это значит, есть, к которому можно обратиться за решением проблемы.
Браузерные инструменты, позволяющие выявлять баги и ошибки.
Легкий старт. Благодаря огромному количеству структурированной информации, обучение React не вызывает проблем.
После обсуждений для продолжения работы и рефакторинга существующих дешей мы выбрали React. Он полностью отвечал всем нашим критериям.
React: быстрее, удобнее, мощнее
Для начала мы определили общие фрагменты нашего SPA.
В отдельную верхнеуровневую среду мы написали общие компоненты, которые впоследствии переиспользовали.
Мы постарались разбить каждую визуализацию на множество мелких частей. Например прирост, линия, столбик — это отдельные компоненты, имеющие ряд внутренних настроек. Это было невозможно при старом подходе, так как код становился нечитаемым.
Стоит отметить, что в своем проекте мы используем хуки, а не классовый подход. Использование функциональных компонентов проще компонента, основанного на классах. Для него не нужно создавать экземпляр класса и вызывать render() — достаточно просто вызвать нужную функцию. Также хуки упрощают работу с методами жизненного цикла компонента. При их использовании в компонентах, основанных на классах, приходится по-отдельности работать с методами componentDidMount(), componentDidUpdate(), componentWillUnmount(), а при использовании хуков можно просто использовать useEffect.
В свою очередь это позволило еще упростить код и оптимизировать SPA.
Мы также внедрили Recharts как наиболее подходящую библиотеку для построения классических графиков. Одно из основных преимуществ данной библиотеки – это возможность писать собственные компоненты к существующим компонентам верхнего порядка. Это позволило настраивать визуализацию, которую предлагает Recharts в точности как того требует заказчик.
Полное ревью проекта и рефакторинг стоили того
В целом использование React позволило уйти от концепции фреймов на одной странице. Также повысилась скорость работы BI приложения за счет Virtual DOM, который позволяет странице немедленно получать ответы от сервера и отображать обновления. Благодаря переиспользованию компонентов, мы смогли существенно сократить время разработки новых форм визуализации. А нисходящий поток данных существенно упростил отладку багов. Мы также добавили TypeScript для статической типизации и React-Redux для разделения логики и представления.
Мы не побоялись провести масштабное ревью всего проекта и потратить время на рефакторинг. Хотя в данной статье речь идет исключительно о frontend части, мы также обратили внимание на backend: переосмыслили недостатки, выявили особенности текущей реализации и оттолкнулись от потребностей проекта. Конечно, некоторые инструменты пришлось изучать — например Redux-Saga, где у нас не было опыта и экспертизы.
Благодаря масштабному рефакторингу мы добились реактивности и простоты нашего SPA и безусловно потраченное время стоило усилий. На текущем этапе развития мы имеем гораздо более удобный и современный продукт. Главный совет: не бойтесь рефакторинга. Это болезненный, но определенно оправданный опыт.
