Баг-репорты в приложении (модули для webview, Tauri и Flutter)

Почему баг-репорты в приложении собираются модулями, а не загрузчиком

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

Тестировщик, который нашёл проблему в сборке, нажимает кнопку модуля, и отчёт идёт тем же путём, что и сообщение с сайта.

Модуль для webview и Tauri: bugfix-app.js

Баг-репорты в приложении на webview и Tauri собирает файл bugfix-app.js: он самодостаточен и не зависит от фреймворка. Что он приносит с собой:

• интерфейс в изолированном shadow-DOM;
• офлайн-очередь в localStorage;
• идентификатор устройства;
• определение платформы и масштаба шрифта;
• включение флагом enabled, обычно только в тестовых сборках.

API состоит из двух вызовов:

BugfixApp.init({ project, version, enabled, position, color, button })
BugfixApp.send('bug', text, contact)

init добавляет плавающую кнопку и форму. send работает без собственного интерфейса и подходит приложениям, у которых своя кнопка.

Скриншот снимается, если в сборке есть html2canvas. Если его нет, сообщение уходит без картинки, и модуль не падает.

Модуль для Flutter: bugfix_flutter.dart

Баг-репорты в приложении на Flutter собирает файл bugfix_flutter.dart. Он решает ту же задачу средствами фреймворка:

• скриншот корневого RepaintBoundary в PNG;
• очередь, которая отличает «нет сети» от «отказа по существу»;
• пауза 16 секунд между отправками, потому что антиспам пропускает одно сообщение в 15 секунд;
• список «Мои обращения» с перепиской и непрочитанными ответами;
• контекст приложения.

Один ящик для сайта и приложения

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

У сообщения один из четырёх видов: bug, idea, confusion или other. Знакомые синонимы (unclear, question, feature, error, crash) приводятся к ним автоматически. Незнакомое слово становится other, поэтому сообщение не пропадёт из-за ярлыка.

Типичные случаи: тестировщик сообщает о проблеме из тестовой сборки; у продукта есть и сайт, и приложение, а список проблем нужен один; приложение со своим интерфейсом вызывает send из собственной кнопки.

Как подключить баг-репорты в приложении по шагам

1. Добавьте адрес базы Bugfix в connect-src политики безопасности приложения.
2. Вендорьте файл, то есть положите копию в свой проект, и не подключайте внешний загрузчик.
3. Инициализируйте модуль с гейтом для тестовых сборок.

Канонические адреса файлов: https://bugfix.asibots.pro/bugfix-app.js и https://bugfix.asibots.pro/bugfix_flutter.dart.

Ограничения, которые нужно учесть

У схемы есть границы:

• Внешний загрузчик виджета сайта в приложении не подходит. Модуль должен быть вендорным файлом.
• Флаг enabled рассчитан на тестовые сборки, поэтому в боевой сборке модуль обычно не активен.
• Для скриншота в модуле webview нужен html2canvas в сборке. Иначе отчёты уходят без него.
• Модуль Flutter ждёт 16 секунд между отправками.
• Вид сообщения принимает одно из четырёх значений. Всё остальное сохраняется как other.

Частые вопросы

Почему баг-репорты в приложении нельзя собирать тегом с сайта?

Политика безопасности приложения и офлайн-режим режут внешний скрипт. Поэтому приложения используют модули, которые копируются в проект: bugfix-app.js для webview и Tauri, bugfix_flutter.dart для Flutter.

Что будет, если в сборке нет html2canvas?

Сообщение уйдёт без скриншота, и модуль не упадёт.

Что происходит с видом сообщения, которого Bugfix не знает?

Допустимые виды: bug, idea, confusion и other. Знакомые синонимы приводятся к ним, а незнакомое слово становится other, так что сообщение не теряется.

Читайте также

• Виджет баг-репорта
• Обратная связь с пользователями
• Автоматизация баг-трекинга