05 Понятие кастомизации

Cлоистая структура фронтенда Luxms BI

Конструктор итогового вида фронтенда Luxms BI собирается из следующих элементов:

1. Коробочный вид компонентов текущей версии веб-клиента. Определяется пакетом luxmsbi-web-client.
2. Текущая тема, определяющая цветовую палитру, тени, бекграунд и набор цветов по умолчанию для графиков.
3. Текущая локализация.
4. Переопределение компонентов-строительных блоков из ресурсов (набор таких компонентов ограничен и будет приведен позже).
5. Обусловленные разделом уровни стилизации. Например переопределение компонентов, тем и стилей только для конкретного атласа. В случае стилей - и для конкретного дешборда. В случае дешей - указание кастомного компонента только у конкретного(ных) деша(ей).

Помимо этого, для раздела dashboards атласа возможно подключить глобальные файлы стилей, поместив их в раздел resources текущего атласа, ds_res или родительских атласов (подключаются на страницу при помощи тега <link>): _global.css или (styles.css). Такой файл будет на всех дешбордах атласа. В случае с ds_res - на всех атласах инстанса вообще.

Так же, учитывая ролевые особенности родительских атласов и ds_res, вы можете разместить файлы стилей _global.css в каждом из них и по итогу получить несколько подключений файлов стилей, по приоритету:

• сначала стили ds_res (если есть - будут подключаться к каждому атласу и его дешбордам)
• затем цепочка стилей родительских атласов (только для дочерних атласов и их дешбордов)
• стили текущего атласа (для всех дешбордов текущего атласа)
• Стили для текущего дешборда текущего атласа будут дополнительными стилями. Такой файл для дешборда с id = 1 будет называться styles.dboard=1.css

Под кастомизацией фронтенда Luxms BI мы будем подразумевать ситуацию, когда требования вашей бизнес-логики выходят за рамки коробочного функционала, предоставляемого фронтендом, и достичь ваших целей вы можете только работая с пунктами 2 - 4 выше.

Как достигается сама кастомизация?

Основной механизм, используемый в проекте luxmsbi-web-client для кастомизации строительных компонентов, дешлетов, тем и стилей: запрос на наличие соответствующих файлов в разделе resources в иерархии атласов перед тем как webpack займется построением дерева компонентов для билдования. Иерархия таких файлов работает так же, как в случае с глобальными стилями выше.
По итогу используется файл, ближайший в иерархии к текущему разделу (атласу, например).

Рассмотрим принцип кастомизации строительного блока страницы:

В проекте luxmsbi-web-client есть компонент-обертка LoadFromResources, который, перед тем как отдать webpack компонент MyComponent.tsx, проверяет наличие файла MyComponent.js (это должен быть собранный React-компонент) в разделе resources текущего атласа и если он там присутствует, то использует его, если нет - идет в родительский атлас за одноименным ресурсом (поднимаясь выше по уровню вложенности атласа), если файла нет ни в одном из родительских атласов, то в ds_res, а если и в нем нет - вставляет коробочную версию компонента (из папки src проекта ).

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