Рекомендации, для сохранения обратной совместимости при обновлении платформы:

1. По максимуму используйте встроенный в платформу функционал и минимизируйте количество JS кода. Через JS можно получить доступ во внутренние структуры системы, у которых нет обратной совместимости и они могут быть изменены в любой момент.
2. Минимизируйте в JS коде обращение к DOM элементам, стилям, CSS классам. Эти сущности могут измениться в любой момент.
3. Используйте JS API, везде где это возможно. Например, для получения данных виджета можно залезть во внутренние структуры объектов, а можно вызвать функцию API. Вызывайте функцию. Мы поддерживаем обратную совместимость всех функций. Либо обязательно предупредим, если поведение функции изменилось.
4. Пишите валидный JS/HTML код, чтобы избежать undefined behavior, в противном случае, после обновления поведение может измениться.
5. Читайте особенности обновления, где мы предупреждаем о вероятных проблемах, которые выявили.
6. Если много JS/Python кода, то нужно тестировать результат после обновления. Мы используем для этого автоматическое сравнение скриншотов дашбордов инструментом BackstopJS.

Общие рекомендации:

1. Для установки фильтра в виджет не нужно добавлять еще один виджет «Фильтр», чтобы повлиять на третий виджет. Достаточно установить фильтр (visApi.setFilterSelectedValues(id виджет, где происходит клик)) в виджет, где происходит клик. Например, если есть карта, в которой вы хотите повлиять на другой виджет, то в коде карты нужно написать visApi.setFilterSelectedValues(id карты).
2. Для показа числа из данных (рисунок 1) не нужно использовать «Пользовательский» виджет. Достаточно использовать виджет «Текст», в форматировании которого можно взять числа из данных и отобразить нужным образом. Например: @array[0] + @array[1]. Таким образом, мы взяли и сложили первые два числа из данных. В форматировании можно использовать JS код. Например, Math.round(@array[2]). Округление третьего числа из данных. Рисунок 1
3. Если отредактировали код, а потом решили его оставить стандартным, то лучше сбрасывать код на стандартный в настройках виджета и запрещать редактирование кода. Если добавится какое-то новое поле в платформе у этого типа виджета в коде, то у отредактированного кода этого поля не будет, а у стандартного оно появится и виджет сможет использовать какой-то новый функционал.
4. Старайтесь не добавлять JS файлы библиотек, которые уже используются платформой, в противном случае возможны конфликты. Список используемых платформой библиотек можно посмотреть в руководстве разработчика.
5. Не использовать кастомные ajax запросы в коде для установки фильтра, получения данных и т.д., так как это может привести к непредвиденным последствиям, после которых платформа может работать нестабильно. Для таких случаев есть функция visApi(), в которой есть все необходимые функции: установка фильтра, запрос данных по виджету, drilldown, drillup, подписка по установке фильтра и многое другое.
6. Старайтесь не добавлять JS файлы от разных версий одних и тех же библиотек, в противном случае возможны конфликты.
7. Когда вы используете одинаковую логику для многих виджетов, то лучше создать JS файл на сервере, в файле которого создать глобальную функцию, например (window.myAdditionalLogic = function (parameter1, parameter2, ...) {}), и внутри нее написать всю логику. А в самом виджете просто вызывать эту функцию с нужными параметрами (window.myAdditionalLogic()).
8. Не используйте в коде виджета получение данных от другого виджета (visApi.getWidgetData()), если эти полученные данные далее не будут использоваться. Лишние запросы нагружают систему.
9. Для получения выбранных значений в виджете, используйте функцию visApi.getSelectedValues() вместо visApi.getWidgetData(). Так как visApi.getWidgetData() запрашивает данные с сервера, таким образом, идет излишняя нагрузка на сервер.
10. Не выносите неиспользуемые виджеты за границу дашборда. Вместо этого удаляйте их, если они больше не используются. Из-за таких виджетов дашборд загружается дольше.
11. Не добавляйте в проекты JS и CSS библиотеки, если вы не уверены в том, что они ничего не поломают на существующем проект.
12. Старайтесь всегда добавлять в проект только минифицированные файлы JS или CSS. Обычно они называются с приставкой min. Например, tippy.min.js.
13. Не добавляйте в проекты большие JS и CSS файлы, так как каждый добавленный JS или CSS файл увеличивает время загрузки дашборда.
14. Старайтесь не оставлять в коде вывод в консоль (console.log, console.warn, console.error и т.д.). Если при работе дашборда возникают какие-то проблемы и разработчикам приходится исследовать код виджетов, то в консоль будет сыпаться лишняя информация, которая затруднит поиск проблемы.
15. Не используйте стандартные виджеты («Гистограма», «Текст», «Круговая» и т.д.), чтобы отрисовать кастомный виджет (например, Dragon D3). Вместо этого используйте «Пользовательский виджет». У стандартных виджетов есть свои настройки (легенда, ось Х, ось Y, настройки фильтра, таблицы и так далее), которые, скорее всего, не будут влиять на отрисованный виджет Дракон, к примеру. Тут спорный момент. Конечно, ничего не мешает подстроить Дракон таким образом, чтобы он использовал настройки другого типа виджета. Но лучше использовать свой «пользовательский» виджет, который будет добавляться на дашборды с помощью Ribbon.
16. Не редактируйте код виджета «Фильтр», чтобы отрисовать заголовок слева. Вместо этого добавьте слева виджет «Текст».
17. Старайтесь использовать фильтры в настройках «OLAP», где это необходимо. Не используйте вместо этого виджет «Фильтр», который будет вынесен за границы дашборда, и применять фильтры по умолчанию.
18. Старайтесь не редактировать название серий в коде виджета. Вместо этого редактируйте название серии в настройках виджета «Настройка серий и сегментов».
19. Старайтесь не добавлять все файлы JS и CSS сторонней библиотеки. Внимательно читайте документацию и используйте только те файлы, которые необходимы для работы библиотеки. Обычно такие файлы лежат в папке dist. Например, для библиотеки Leaflet достаточно добавить только dist/leaflet.js, все остальные файлы не нужны (например, папка src) – это исходные файлы.