Эй!

На прошлой неделе наша команда в 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 я подумал о двух других методах, которые могут сработать.

  1. Переупаковка приложения с помощью специального скрипта, который обеспечит логику 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»: {…}}

Самый быстрый способ проверить это - попытаться оценить предупреждение:

Теперь все, что нам нужно сделать, это:

  1. Напишите полезную нагрузку RTL-ing
  2. Открытые команды с включенной удаленной отладкой
  3. Найдите окно чата
  4. Вставить скрипт в указанное окно
  5. Выгода

Полезная нагрузка вместе с программой выполнения команд на основе Python (она отвечает за запуск отлаженных команд и внедрение сценария) доступна здесь, она поддерживает как Windows, так и Mac.

Я также упаковал его в расширение для Chrome, которое использует ту же полезную нагрузку, что и сценарий содержимого.

Краткий обзор

  • Мы говорили о нескольких потенциальных механизмах внедрения скриптов в электронные приложения.
  • Мы исследовали протокол DevTools и увидели, как его использовать для оценки полезной нагрузки js.
  • Мы добавили достойную поддержку RTL для Microsoft Teams.

Ресурсы и благодарности:

Не стесняйтесь, чтобы оставить комментарий ниже :)