Доработка архитектуры фронтенда

Материал из CIToRUS wiki
Перейти к: навигация, поиск

Анализ текущего состояния картографического сегмента Платформы автоматизации «ЦИТОРУС»[править]

Проблемы в архитектуре приложения

1. Взаимозависимость модулей и git-репозитариев (kedr может зависеть от base-js, но не наоборот). 2. Нечеткая направленность модуля base-js (нет единого экспорта моделя, нарушается принцип единой ответственности). 3. Разброс по разным репозитариям и файлам сходного функционала (например, плагинов Leaflet). 4. Различные системы сборки js-файлов - через конфиг вебпака и через теги <script> на странице приложения. 5. Внешние загрузки скриптов. 6. Слабая документация системы. 7. Засорение глобальной области видимости.

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

Направления решения архитектурных проблем:

1. Внедрение npm-репозитария. 2. Разбивка монолитного base-js на мелкие модули. 3. Объединение концептуально близких файлов в единых репозитариях. 4. Обеспечение переиспользуемого функционала карты и близких элементов для построения однотипных приложений. 5. Создание единой точки сборки js-файлов проекта через bundle.js

Глобально, поскольку экосистема состоит из похожих приложений со смежным функционалом, стоит пересмотреть место рпозитария base-js и перейти к репозитарию-каркасу приложений. Такой каркас содержал бы основне компоненты, которые при необходимости кастомизировались бы в готовых приложениях.

Архитектура могла бы выглядеть так:

npm-хранилище с модулями -> шаблон приложений -> готовые кастомизированные приложения.

При таком подходе время, необходимое на разворачивание нового проекта, сократилось бы.

Разбивка base-js на модули.

- Разделить base-js/controls и base-js/widgets на репозитарий с реакт-компонентами (опционально - Storybook) и репозитарий с oe.controls - Выделить отдельный репозитарий с сабмодулями для сборки всех Leaflet-плагинов. - Выделить репозитарий (или несколько) для контролов Leaflet (в том числе контролов, которые лежат внутри mapForFD) - Убрать повторяющиеся ссылки на Leaflet-плагины, убрать исходники Leaflet. - Заменить дублирующийся код на es6-импорты из пакетов. - Убрать загрузку скриптов через тег script. Оставить единый бандл.

Компонент карты.

mapForFD превращается в компонент класса Map. - все L.controls из него выносятся. - класс Layer выносится в отдельный файл.

Этот модуль является основным для построения приложения с картой и инициализируется с широким набором опций (например, списком контролов). Неизменной оставить концепцию сторон карты (https://www.figma.com/file/1FINbh2IDFiGy6DvaUSMbn/%D0%A6%D0%98%D0%A2%D0%9E%D0%A0%D0%A3%D0%A1---%D0%AD%D1%81%D0%BA%D0%B8%D0%B7%D0%BD%D0%BE%D0%B5-%D0%B2%D0%B8%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-GUI-%D0%BA%D0%B0%D1%80%D1%82%D1%8B-%D0%BF%D0%BE-%D0%B7%D0%BE%D0%BD%D0%B0%D0%BC?node-id=0%3A1). Каждая из сторон детально прорабатывается, описывается в опциях и проектируется. После этого можно строить карты для тематических приложений.

Переработка модуля карты:

Слева - контекстные атрибутивные данные - отдельный L.control и репозитарий

Сверху - набор контролов (меняется от сервиса к сервису)

Справа - переработка L.Control.MapMenuRight:

- Параметризация отдельными виджетами, - Создание единого API добавления/удаления виджетов из правой панели.

Снизу - набор контролов (меняется от сервиса к сервису).

Каждый из этих контролов может быть необязательным.

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