Эй!
На прошлой неделе наша команда в Microsoft изменила наше приложение для внутриорганизационных коммуникаций - мы перешли со Slack на Teams, службу собственной разработки Microsoft.
Обе службы предлагают аналогичные возможности, у каждой есть свои сильные и слабые стороны; Но им обоим не хватает поддержки RTL (справа налево).
В наших групповых чатах часто используются как английский, так и иврит, и неправильное выравнивание предложений оказывается довольно сложной задачей, «вынуждая» нас использовать слишком много разрывов строк и приводя к ненужной путанице.
Создание RTL-решения для Microsoft Teams
Я хотел почесать собственный зуд, и это заставило меня искать простой способ добавить поддержку RTL для приложения, по крайней мере, временную, прежде чем оно будет поддерживаться изначально.
Я начал с просмотра каталога Teams; Я быстро понял, что, как и Slack, он построен на основе Electron - фреймворка, который позволяет создавать кроссплатформенные настольные приложения с интерфейсными веб-технологиями.
Выше вы можете увидеть типичное дерево каталогов электронного приложения:
- app.asar.unpacked - обычно содержит статические ресурсы и сторонние модули npm.
- активы - изображения, значки и аналогичные статические файлы
- locales - Многоязычные переводы
- app.asar - Упакованное приложение в формате Электронный архив
- electronic.asar - Электронные библиотеки
Легко - просто найдите файл .js, загруженный Teams, в app.asar.unpacked и добавьте туда пользовательскую полезную нагрузку!
По крайней мере, я так думал. При просмотре распакованного каталога приложения были обнаружены только предварительно скомпилированные модули узлов (в основном, несколько .dll).
Следующее, что пришло в голову, - это создание прокси-библиотеки, которая будет внедрять заданную полезную нагрузку; Это было быстро отклонено, так как для моих коллег, использующих Mac, потребовалось отдельное решение.
С проксированием DLL я подумал о двух других методах, которые могут сработать.
- Переупаковка приложения с помощью специального скрипта, который обеспечит логику RTL
2. Попробуйте загрузить приложение в режиме отладки и используйте протокол chrome devtools для внедрения скрипта во время выполнения (используя Runtime.evaluate).
Явным преимуществом последнего является то, что он не будет перезаписан будущими обновлениями, которые, как правило, происходят довольно часто; И вот я решил пойти по второму маршруту.
Запуск команд с сервером отладчика
Electron использует хром в качестве внутреннего механизма, поэтому при запуске электронных приложений можно передавать аргументы, связанные с хромом.
Один из многих полезных параметров, которые вы можете передать, - это «порт удаленной отладки», который позволяет вам подключать удаленный отладчик к каждому окну, создаваемому приложением.
Запустив Teams с флагом, установленным для порта по моему выбору, я мог легко протестировать его, перейдя на страницу chrome: // inspect в Chrome после включения поиска сетевого устройства.
Отлично - похоже на прогресс! Затем я осмотрел окно чата, чтобы понять, с какими элементами мне нужно работать.
Я выделил три набора элементов, которые выигрывают от RTL, а именно:
- Сообщения чата - CSS-селектор `.message-body-content`
- Предварительный просмотр чата (слева) - CSS Selector` .ts-channel-list-entry-preview `
- Ввод текста чата - CSS-селектор `.ts-edit-box .cke_editable`
Что касается логики RTL, я мог бы просто подключить к этим элементам атрибут dir = ”auto” (поддерживаемый большинством основных браузеров), и браузер должен отображать их автоматически.
А теперь о самом уколе.
Из Chrome DevTools Protocol: […] ваше приложение может обнаруживать доступные страницы, запрашивая: http: // localhost: port / json и получая объект JSON с информацией об инспектируемых страницах вместе с адресами WebSocket, которые вы можете использовать в чтобы начать их оснащать.
Звучит многообещающе - давайте посмотрим.
Конечная точка выводит активные окна отлаженного процесса, и, переключаясь между панелями в Teams, мы могли видеть различные URL-адреса отладки веб-сокетов для каждой панели. На данный момент, похоже, меня больше всего интересует окно «Чат».
Пройдя через API с богатым набором протоколов DevTools, мы заметили, что можем оценить полезную нагрузку javascript с помощью метода Runtime.evaluate.
С этого момента общение с приложением довольно простое, мы подключаемся к веб-сокету и можем отправлять команды на основе следующего JSON:
{«id»: someId, «method»: methodName, «params»: {…}}
Самый быстрый способ проверить это - попытаться оценить предупреждение:
Теперь все, что нам нужно сделать, это:
- Напишите полезную нагрузку RTL-ing
- Открытые команды с включенной удаленной отладкой
- Найдите окно чата
- Вставить скрипт в указанное окно
- Выгода
Полезная нагрузка вместе с программой выполнения команд на основе Python (она отвечает за запуск отлаженных команд и внедрение сценария) доступна здесь, она поддерживает как Windows, так и Mac.
Я также упаковал его в расширение для Chrome, которое использует ту же полезную нагрузку, что и сценарий содержимого.
Краткий обзор
- Мы говорили о нескольких потенциальных механизмах внедрения скриптов в электронные приложения.
- Мы исследовали протокол DevTools и увидели, как его использовать для оценки полезной нагрузки js.
- Мы добавили достойную поддержку RTL для Microsoft Teams.
Ресурсы и благодарности:
- Документы протокола Chrome DevTools
- Электронная библиотека Python
- Надеюсь, вы хорошо прочитали!
Не стесняйтесь, чтобы оставить комментарий ниже :)