Особенности разработки интерфейсов 1С на javascript и интеграция с webkit

Давайте разберемся, зачем вообще в 1С делать веб-интерфейсы. Неужели встроенных возможностей не хватает?

• Во-первых, веб-интерфейсы просто красивее. Конечно, на 1С можно создавать визуально приятные формы, но если дизайнер или заказчик предъявляет высокие требования к внешнему виду и взаимодействию, соответствовать всем пожеланиям вряд ли получится. Потому что мы можем использовать только такие компоненты, которые есть в платформе. А веб-интерфейсы позволяют реализовать практически все что угодно.

• Во-вторых, веб-интерфейсы выполняются только на клиенте. И это важное огромное преимущество, позволяющее не выполнять лишние клиент-серверные вызовы. А когда мы делаем интерфейсы на чистом 1С любые динамические изменения интерфейса часто требуют обращения к серверу.

• Кроме того, веб-интерфейсы предсказуемы с точки зрения верстки. Те, кто создавал сложные формы в 1С, знают, насколько трудно адаптировать их под разные разрешения и экраны. В первую очередь, эта проблема связана с тем, что в 1С размеры задаются в условных единицах. Например, ширина 10 – чему равняется эта 10? В зависимости от масштаба она может быть разной. В веб-приложениях с этим намного проще.

• Ну и в целом веб-интерфейсы намного проще разрабатывать, потому что для них есть такие системы, как hot reload – мы можем писать код и сразу же видеть результат без необходимости перезапуска приложения. Это на порядок ускоряет разработку приложения и делает работу с такими интерфейсами сильно проще. Не требуется постоянно перезапускать приложение – в частности, ERP, где только запуск нужно ждать несколько минут.

Веб-интерфейсы активно используются в типовых конфигурациях.

Например, в БСП с помощью веб-интерфейса реализован просмотр результатов полнотекстового поиска.

В сервисе «Распознавание документов» с помощью веб-интерфейса реализован предпросмотр результатов распознавания – вы можете спозиционироваться на конкретном поле в табличной части документа, и оно будет выделено в окне предпросмотра.

Сервис 1С:Штамп позволяет устанавливать штамп ровно в нужное место PDF-документа для того, чтобы его проштампировать.

Новая форма легкого ЭДО из «Библиотеки электронного документоборота» тоже имеет элементы веб-интерфейса.

БухОбслуживание очень богато на красивые и удобные интерфейсы. Например, здесь мы видим монитор руководителя.

А здесь – результат проверки бухгалтерского учета по итогам аудита компании.

Кроме этого, внутренняя CRM сервиса БухОбслуживание тоже имеет веб-интерфейс.

Как видите, веб-интерфейсы уже сейчас используются в типовых, и глупо не пользоваться этими возможностями тогда, когда этим можно пользоваться.

Как это все работает? ПолеHTMLДокумента

Рассмотрим, как это все работает – в первую очередь поговорим, что собой представляет поле HTML-документа:

• В приложениях, которые запускаются на Windows, Linux, Mac, Android, ПолеHTMLДокумента – это встроенный браузер.

• В веб-клиенте – это iframe в браузере.

Но в обоих случаях ПолеHTMLДокумента – это именно браузер, потому что у него есть элементы управления, мы можем указать для него навигационную ссылку и элементы перехода.

С точки зрения внешнего вида ПолеHTMLДокумента – это поле, в которое загружается наша страничка. При этом платформа рисует вокруг него рамки, а это – настоящая боль для дизайнеров, им всегда хочется избавиться от рамок, чтобы получить чистый интерфейс: не как на верхней картинке, а как на нижней.

Но оказывается, что просто так убрать эти рамки невозможно, тем более, что их там на самом деле там две:

• первая рамка – это граница самого поля HTML-документа;

• а вторая рамка, желтого цвета – появляется при активности поля как текущего элемента формы.

Рамку самого поля можно замаскировать – если мы установим ее цвет в фон формы, она просто станет не видна.

А вот убрать активность поля – задача самая сложная. Но здесь можно поиграться с параметрами доступности и пропуска при вводе, и тогда эта желтая рамка исчезнет.

При этом нужно учитывать, что в тонком клиенте и веб-клиенте доступность работает по-разному.

• В тонком клиенте она полностью блокирует все приложение, делая невозможным дальнейшее взаимодействие с ним.

• А в веб-клиенте рамка исчезает, но все остальное продолжает работать.

Для анализа того, что происходит внутри поля HTML-документа, есть очень полезный инструмент – WebInspector. Он позволяет анализировать, что же происходит внутри веб-страницы.

Открыть веб-инспектор можно, кликнув на поле и нажав Ctrl-Alt-Shift-F12.

Самое главное, что есть в этом инструменте – это консоль. С ее помощью можно исполнять JavaScript-код непосредственно в запущенном приложении.

И если мы воспользуемся этой консолью и посмотрим на разных версиях платформы, где какая версия используется, окажется, что:

• в версии платформы 8.3.26 – используется самый современный WebKit, такой же, как в iPhone 15 Pro.

• а в версии платформы 8.3.23 использовался старый WebKit (WebKit 1), после чего его обновили.

И тут хочется задаться вопросом – действительно ли WebKit везде одинаковый?

Нет, он, оказывается, отличается не только для разных платформ, но и для разных операционных систем.

JavaScript активно развивается: фактически каждый год за последние 10 лет выходила новая версия – с новыми спецификациями и новыми возможности.

Я выложил на Gist GitHub специальный скрипт, который можно выполнить непосредственно в консоли и посмотреть, какая версия JavaScript поддерживается конкретно в вашем окружении – в вашей версии платформы 1С и вашей операционной системе.

Выполнив этот анализ, мы можем получить следующую статистику.

• В Windows на платформе 8.3.13 и ранее, пока использовался устаревший движок Internet Explorer, версия JavaScript была 1999-го года

• В Linux, до версии платформы 8.3.23, пока использовался WebKit 1, мы сидели на 1ECMAScript уровня 2015-го года.

• В Windows, начиная с платформы 8.3.14 и до сих пор, используется ECMAScript 2018.

• А Mac, Linux и любой веб-клиент всегда используют самую современную версию ECMAScript.

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

• В версии платформы 8.3.13 и ранее нам обязательно нужно писать на JavaScript в спецификации версии ECMAScript 3 – это связано с ограничениями Windows и Internet Explorer.

• Начиная с версии платформы 8.3.14 мы уже можем для всех ОС использовать ECMAScript 6 и выше – downgrade нужен только для Linux, а под Linux в принципе мало кто разрабатывает.

• А начиная с версии платформы 8.3.24, когда Linux обновили, нашим ограничением является ECMAScript 2018, потому что это урезанная версия WebKit, которая используется в Windows.

Вывод: если для вашего решения требуется поддерживать разные версии платформы, нужно разрабатывать на JavaScript с учетом этих ограничений. И поскольку у разных клиентов могут использоваться разные версии JavaScript, нужно приводить наш код к такому, который будет исполняться на разных версиях.

Как загрузить приложение в поле HTML-документа?

Технически все выглядит очень просто:

• у нас есть элемент – поле HTML-документа;

• и есть строковый реквизит, который связан с этим полем.

Первый вариант загрузки – это указать в значении реквизита непосредственно адрес, откуда будет загружаться приложение. Мы можем это сделать тремя способами.

• Указать адрес на HTTP-сервер, где будет развернуто наше приложение.

• Указать путь к локальному файлу на диске с этим приложением. Платформа 1С это допускает, но вариант не очень хороший, и современные браузеры на такое ругаются, потому что это небезопасно – кто-то может влезть и подменить эти файлы прямо в момент исполнения приложения.

• И третий вариант, который не все знают – можно сформировать навигационную ссылку на временное хранилище. На слайде показано два варианта загрузки данных во временное хранилище из разных типов макетов: первый вариант – из макета HTTP-документа, второй – из макета двоичных данных. И такая ссылка будет загружаться в поле HTML документа.

И второй принципиально другой вариант – это записать в реквизит сам текст HTML-документа. В этом случае платформа сама его упакует в файл и доставит до поля HTML-документа.

Однако современные веб-приложения намного сложнее, чем кажется:

• они состоят не из одного HTML-файла, а из множества исходников, зависящих между собой;

• у них есть правила компиляции – как эти исходники должны быть между собой связаны;

• у них есть библиотеки, которые нужно использовать как зависимости;

• и в результате всей компиляции приложения в папке dist тоже получается много скомпонованных CSS и JS-файлов, которые будут в итоге загружены в корневой файл index.html.

А нам хочется, чтобы файл был один – чтобы мы сразу могли его загрузить, например, во временное хранилище и отобразить в поле HTML-документа.

Получается, что использовать такое многокомпонентное приложение в 1С можно только в следующих случаях:

• Если мы опубликуем его на HTTP-сервере. Это будет работать, но возникнут накладные расходы на разворачивание веб-сервера и публикацию на нем, а этим заниматься не хочется.

• Если мы выгрузим файлы приложения во временный каталог на диске. Но это тоже не очень хороший вариант, потому что у него есть проблемы безопасности.

В итоге возникает проблема тонкого клиента файловой базы, потому что заниматься для него разворачиванием отдельного HTTP-сервера не хочется. Файловые базы обычно используются у маленьких клиентов – а зачем им нужен HTTP-сервер? Следовательно, использовать такую систему для мелких тиражных решений не получится – просто потому, что на разворачивание всего этого требуется слишком много накладных расходов.

Хочется решить эту проблему по-другому. Хочется сказать компилятору, чтобы он вместо получения на выходе множества разных файлов, собрал все наше приложение в один файл. И тогда мы сможем его поместить во временное хранилище и загрузить в наше поле HTML-документа.

При этом у нас остается проблема с тем, что браузеры работают на определенной версии JavaScript. А мы хотим использовать современные библиотеки, которые написаны на современном JavaScript.

И писать приложение мы тоже хотим на современном JavaScript, используя все новые возможности. При том, что работать наше приложение будет только с ограниченным JavaScript.

Для решения этой проблемы есть два принципиально разных инструмента – компиляторы Babel и TypeScript. Оба они позволяют «перевести» современный JavaScript в более старую, совместимую версию:

• Babel – транспилирует современный JavaScript в код, который будет работать в старых браузерах или клиентах 1С.

• TypeScript – язык, основанный на JavaScript, но с поддержкой статической типизации. Также компилируется в обычный JavaScript, включая старые версии.

Что использовать – TypeScript или JavaScript?

• Кажется, что на всех новых проектах используют TypeScript. Его выбирают потому, что он типизирован. А разработчики любят типизированные языки – они позволяют выявлять ошибки на ходу. Именно поэтому EDT сейчас активно продвигает идею использования аннотации «@strict-types» и типизирующих комментариев. Потому что это позволяет ловить ошибки еще на моменте разработки.

• Де факто TypeScript сейчас стандарт. И на нем делают не только веб-приложения:

  • Например, всеми нами любимый VS Code тоже написан на TypeScript.

  • И подавляющее большинство мобильных приложений, которые используют React Native, тоже разработаны на TypeScript.

Теперь давайте рассмотрим способы доставки веб-приложения в поле HTML-документа.

Первый путь – цепочка (2) (1) – мы берем данные приложения из информационной базы, выгружаем все это из архива в локальные файлы и загружаем в тонкий клиент. Так работает всем известная консоль кода на основе редактора Monaco – bsl_console.

Второй вариант – стрелочка (3) – мы можем данные приложения напрямую из базы загрузить в тонкий клиент. Для этого нам можно использовать один из двух возможных вариантов:

• либо записать в реквизит адрес временного хранилища;

• либо напрямую выгрузить это все в строку с HTML и записать ее в реквизит так.

Но есть проблема с большими скомпилированными приложениями, потому что в тонком клиенте запись в реквизит строки с HTML работает нестабильно. И очень сложно подобрать версию платформы, в которой это будет работать хорошо.

Поэтому стабильным считается вариант с использованием адреса временного хранилища.

Следующие две стрелки образуют четыре возможные комбинации:

• либо с публикации файла на HTTP;

• либо с информационной базы

нужно доставить:

• либо до тонкого клиента;

• либо до веб-клиента.

Но тут тоже есть свои нюансы: адрес временного хранилища приезжает в веб-клиент с проблемами, потому что платформа помечает его заголовком application/octet-stream. А современные браузеры вместо того, чтобы загрузить эту начинку в iframe, начинают инициализировать загрузку файла. В итоге мы не видим внутри приложение, а просто получаем скачиваемый файл.

Приходится делать отдельные ветки условий, где прописывать поведение для тонкого и веб-клиента:

• в веб-клиенте считывать всю HTML-строку полностью и помещать ее в реквизит;

• а для тонкого клиента уже готовить адрес временного хранилища.

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

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

Как обмениваться информацией между ПолеHTMLДокумента и платформой

Следующая большая тема, о которой нужно поговорить, это как обмениваться информацией между платформой и загруженным в поле HTML-документа приложением.

Есть два направления обмена:

• Первое – это мы хотим из 1С вызвать JavaScript, чтобы что-то с ним сделать.

• А второе – мы хотим из JavaScript вызвать 1С, чтобы получить данные либо отправить определенное действие – например, чтобы 1С полезла на сервер и что-то спросила.

Для обмена информацией между платформой и полем HTML-документа в 1С есть три события, которые давно существуют:

• Первое событие – ПолеHTMLПриИзменении. Оно срабатывает в момент, когда мы меняем значение навигационной ссылки, хранящееся в реквизите. Это событие хорошо работает для случаев, когда, например, нужно проводить OpenID-аутентификацию. Мы проводим аутентификацию, происходит редирект, и в рамках редиректа в фрагменте URL возвращается новый тикет – мы можем его оттуда вычитать и в дальнейшем использовать. Но для регулярного обмена сообщениями это событие не подходит, потому что нужно постоянно делать редиректы, а это накладное дело.

• Второе событие – ПолеHTMLДокументСформирован – возникает тогда, когда HTML-документ полностью загружен в соответствующее поле. Очень нестабильная штука, потому что современным веб-приложениям мало быть полностью загруженными в память – они после загрузки HTML начинают выполнять дополнительные функции инициализации, инициализируют виртуальный DOM. Поэтому фактически событие ПолеHTMLДокументСформирован срабатывает преждевременно – до того, как приложение реально готово к работе. Проще его вообще не использовать, а чтобы узнать, что приложение подготовлено, лучше попросить его оповестить тебя каким-то другим образом.

• Третье событие – ПолеHTMLПриНажатии. Фактически это единственный наш способ коммуникации. С его помощью мы можем эмулировать из JavaScript разного рода события – например, нажатие кнопки мыши: сказать, что эта кнопка виртуально нажата. Таким образом мы в 1С получим это событие.

Есть еще несколько бесполезных событий – в платформе версии 8.3.15 над полем HTML-документа появились три кнопки: «Сохранить», «Печать», «Предварительный просмотр». Очень жаль, что их вообще нельзя убрать.

А в платформе версии 8.3.19 появились методы для управления этими кнопками – но опять же для нашей задачи коммуникации с приложением мы их использовать не можем.

Итого, если мы хотим обмениваться с JavaScript, у нас есть принципиально два подхода:

• Первый – это копить сообщения где-то внутри до тех пор, пока 1С их не прочитает. Это потребует от 1С делать какой-то тайм-аут по зачитке. А это значит, что 1С не сразу будет получать информацию, а только тогда, когда у нее тикнет следующий тайм-аут. А если тайм-ауты будут частые, 1С при постоянном опросе может начать «зависать».

• А второй – это имитировать нажатие служебной кнопки, чтобы отдать 1С событие нажатия на элемент.

Оба этих подхода – асинхронные. А это значит, что сделать синхронный вызов из JavaScript не получится. И тут мы уже сразу должны закладываться на то, что будем работать с асинхронщиной.

Как все это выглядит в итоге? Мы создаем в JavaScript две кнопки:

• одна – для входящих сообщений

• другая – для ответов

И дальше говорим JavaScript:

• дерни нажатие первой кнопки – RequestForwarder;

• подпишись на нажатие второй кнопки – ResponseForwarder.

1С со своей стороны:

• ловит событие нажатия кнопки RequestForwarder;

• вычитывает данные, собирает их, обрабатывает;

• и дергает эмуляцию нажатия кнопки ResponseForwarder в ответ.

JavaScript ловит событие нажатия кнопки ResponseForwarder и обрабатывает данные, которые получены из 1С.

А поскольку все это асинхронно, это в итоге приходит к каше пакетов, потому что из JavaScript можно одновременно вызвать множество запросов. А нам для каждого сообщения нужно всегда дослать именно тот ответ, который ему предназначен.

С прямым вызовом из 1С в JavaScript все намного проще, потому что у 1С есть объект Элементы.ПолеHTML.Документ, который позволяет дергать содержимое HTML-документа напрямую. Мы можем прямо к нему обратиться и дергать через него встроенные в веб-приложение js-методы.

Выглядеть это будет примерно так:

• На уровне JavaScript описывается глобальный объект с нужными методами.

• А на уровне 1С мы получаем доступ к этому объекту и можем вызывать его методы напрямую – например, чтобы отправить данные или инициировать действие.

Почему фреймворк React

Теперь о том, почему я фокусируюсь на фреймворке React и считаю, что нужно использовать именно его.

Есть четыре больших фундаментальных решения, на которых можно разрабатывать веб-приложения: Angular, React, Vue и Svelte.

Если мы посмотрим на графики Stack Overflow Trends, то примерно с 2019 года React выстреливает и улетает вверх.

Количество GitHub-репозиториев для React примерно с этого времени тоже кратно возрастает.

У NPM – пакетного менеджера Node.js, который позволяет реализовать в JavaScript библиотечный подход – точно так же в тегах по загрузкам React улетает вперед.

Подписчики Twitter, у которых раньше Angular был де-факто стандартом для бизнеса, сейчас все чаще используют React.

Google Trends точно так же по количеству запросов на слово React улетает вперед по сравнению с запросами по Angular, Vue и Svelte.

Как собрать свое приложение на React

Давайте посмотрим, каким образом можно собрать свое приложение на React в один файл, чтобы затем загрузить его в 1С и использовать там.

Существуют два основных подхода к сборке таких приложений:

• Первый – с использованием Webpack. Это старенький и проверенный временем инструмент: у него большая экосистема плагинов, стабильная работа и хорошая совместимость. Например, Vanessa Editor собран именно на Webpack.

• Второй подход – современный, модный, молодежный – это сборка через Vite. Читается как «Вит», а не «Вайт», потому что это французское слово.
  Vite быстрый, шустрый, суперсовременный, но его приходится немного поднастраивать, чтобы он переводил JavaScript в более старую версию, которая будет совместима с платформой 1С.

Давайте посмотрим, как выглядит процесс сборки React-приложения, которое можно загрузить в 1С.

Итак, нам нужно создать приложение Vite:

• вводим команду
  npm create vite@latest

• указываем название проекта – test1c;

• выбираем, какой фреймворк будем использовать – в данном случае, React;

• указываем конфигурацию языка, на котором мы будем писать – TypeSctipt + SWC;

• и после этого подтягиваем все зависимости этого приложения, выполнив в его каталоге команду
  npm install.

Дальше запускаем dev-сервер, выполнив команду

npm run dev

И можем открыть наше приложение по адресу http://localhost:5173 – начать его разрабатывать и сразу видеть результат разработки в браузере.

Теперь для того, чтобы собрать весь результат в один файл, нам нужно поставить дополнительный плагин – vite-plugin-singlefile. Это делается командой

npm install vite-plugin-singlefile --save-dev

После этого нам нужно будет импортировать этот плагин в настройках компиляции Vite (в файле vite.config.ts), добавив строку:

import { viteSingleFile } from ‘vite-plugin-singlefile’

И указать этот плагин в списке плагинов наравне с плагином React:

export default defineConfig({
plugins: [
react(),

viteSingleFile()

],

})

После этого, выполняя команду сборки npm run build, мы сразу получим в dist наш заветный единый HTML-файл.

Теперь нам нужно его понизить до версии, которая будет работать в WebKit для Windows. Для этого в настройках компиляции Vite (в файле vite.config.ts) нужно в качестве таргета сборки указать более старую версию JavaScript (es2018), добавив строки:

build: {
target: "es2018"
}

И то же самое нужно сделать в самом TypeScript, добавив в tsconfig.app.json следующие параметры сборки:

{
"compilerOptions": {
"target": "ES2018",
"useDefineForClassFields": true,
"lib": ["ES2018", "DOM", "DOM.Iterable"],
"module": "ES2015",
"skipLibCheck": true,
…

Обратите внимание, что для параметра module тоже нужно отдельно указать систему загрузки – не современную, а более старую, 2015 года.

Таким образом в результате команды npm run build будет собрано правильно настроенное одностраничное React-приложение. Мы сможем его загрузить в макет двоичных данных и начать использовать.

Пакет для интеграции 1С и React-приложения

Я разработал небольшую библиотеку, которая дает привычный для JavaScript-разработчиков API для получения данных из 1С – ее можно установить через npm или скачать исходники с GitHub.

• Мы можем запросить данные из 1С через V8Proxy.fetch и асинхронно получить ответ. Причем сразу в трех вариантах – либо как текст, либо как JSON, либо как BLOB:

  • Отправляем из 1С структуру массивов, а в JavaScript сразу получаем JSON-объект.

  • Или передаем из 1С двоичные данные, а в JavaScript сразу получаем BLOB-объект.

• Кроме того, в библиотеку входит React-хук, который синхронизирует состояние компонентов React с реквизитами формы 1С. Фактически, мы можем из React сказать: «Установи новое значение в реквизит формы 1С "Номер"». И он его установит.

Выводы

Резюмируем сказанное:

• Веб-приложения для работы в 1С используются повсеместно, и будут использоваться и дальше. Стоит подключиться к этому движению и тоже попробовать.

• Мы очень ждем, что WebKit в Windows будет обновлен. И надеемся, что они будут выпускаться синхронно, чтобы мы могли использовать современные возможности JavaScript. Это круто.

• Ну и глобальный совет – учите соседние стеки, чтобы делать стек 1С лучше.

Вопросы и ответы

У фирмы «1С» есть стандарт 730, который гласит: «Не следует использовать поля с HTML-документами в случаях, когда возможно использование элементов управления платформы 1С:Предприятие». Здесь этот стандарт как-то применяется?

Есть возможности, которые на 1С сделать невозможно. И я в самом начале показывал примеры, где в самих типовых конфигурациях используются эти возможности.

Каждое такое использование должно быть обосновано. Всегда лучше сначала пытаться использовать стандартные элементы. Но если мы хотим делать интерфейсы, понятные пользователям – с определенными дизайнерскими элементами, с возможностями, которые невозможно сделать на чистом 1С – это путь, позволяющий их сделать.

А как это вообще все работает на мобильных платформах, мобильных клиентах?

Так же, как веб-клиент работает на мобильных устройствах – с теми же возможностями и ограничениями.

У меня вопрос по поводу производительности. Есть условно небыстрый и немощный терминал, на котором типовой интерфейс работает недостаточно быстро. Можем ли мы получить потенциальный прирост производительности, если переориентируем форму на HTML-документ? Или это всегда дополнительные накладные расходы и еще большее падение производительности?

Бывает по-разному, и зависит от того, какой интерфейс вам нужен.

Какой-то элементарный интерфейс, наверное, получится сделать побыстрее. Но сам я задачу повышения производительности с помощью перехода на веб-интерфейс не решал, и у меня нет показателей, которыми я мог бы подтвердить свои слова.

С другой стороны, я точно знаю, что, используя JavaScript, можно использовать возможности параллельной работы. А в коде клиента 1С мы параллельность использовать не можем.

А в JavaScript – в том числе, внутри WebKit – мы можем создавать отдельные пространства, внутри которых будет параллельно выполняться код. И за счет такой механики мы можем делать ускорение для сложных алгоритмов. Например, в Vanessa Editor внутри приложения есть три фоновых процесса:

• один отдельный процесс показывает картинку;

• второй процесс запускает фоновый рендеринг элементов, чтобы интерфейс не зависал;

• и третий, который отрабатывает механику LSP-серверао, чтобы работал автокомплит.

И эти все три процесса работают одновременно. Такие штуки можно делать на WebKit, а на 1С нельзя. Но это, наверное, не совсем то, что нужно для терминалов, которые должны просто работать быстро.

Не пробовали ли вы использовать сервер-сайд рендеринг (SSR)? С ним и приложение будет запускаться быстрее, и событие будет отрабатывать в нужный момент.

С одной стороны, практически все современные приложения сейчас все-таки идут по пути SPA, чем по SSR. А с другой стороны, у того же React есть расширение Next.js, которое тоже поддерживает серверные компоненты и SSR.

Дело в том, что у любого приложения есть элементы подготовки и запуска. Даже если мы будем использовать не React, а чистый JavaScript, нам для работы часто бывает нужно загрузить какие-то компоненты – например, тот же просмотрщик картинок. И пока библиотека этого просмотрщика картинок не будет инициализирована, мы не сможем загрузить в приложение картинку так, чтобы методы этого просмотрщика были доступны – он все равно не будет отрабатывать вовремя.

Поэтому самый стабильный способ сообщить о готовности к работе – это после завершения инициализации приложения отправить в 1С свою команду. В любых других случаях мы можем наткнуться на то, что при попытке обратиться к объекту JavaScript он еще не существует. Потому что еще не исполнился код, который добавит этот объект.

Поэтому какое угодно приложение не встроить – сначала его нужно адаптировать под 1С, чтобы оно могло рассказать 1Су о том, что готово к работе. Но это обычно не очень сложно.

Как поведет себя поле HTML-документа в тонком клиенте на старых операционках? К сожалению, бывают клиенты и на XP, и на семерках. Какие могут быть тут сюрпризы?

Я знаю, что ограничение WebKit на старых версиях платформы как раз было связано с поддержкой XP. Но 1С сейчас уже отказывается от поддержки XP. Microsoft уже отказался. Chrome уже отказался. Касперский уже отказался. Все отказались, а 1С держался до последнего.

Хочу сделать небольшой комментарий по поводу желтой рамки вокруг поля HTML. Недавно приходилось решать задачу добавления на форму маленькой анимированной кнопки. И когда вокруг этой кнопки появлялась желтая рамка, эта анимация терялась – я искал решение, как это можно вообще избежать. И удалось найти вариант, при котором она появляется только на момент клика – в этом случае можно одновременно программно добавить на форму элемент, перенести на него фокус через «ЭтаФорма.ТекущийЭлемент», а потом удалить. Таким образом эта рамка появляется только в момент клика пользователям. В остальных случаях она пропадает.

Да, это действительно так. Даже этот случай, который я показывал с изменением доступности и пропуска элемента, он не будет работать, если поле HTML-документа на нашей форме – единственный элемент. Потому что платформа все равно будет пытаться фокусироваться на единственном элементе – даже если он недоступен.

Проблема есть. Совсем избавиться от нее даже в таком моргающем виде не получится. По крайней мере сейчас таких возможностей нет. Может быть кто-нибудь придумает.

Вы сказали, что BSL-консоль выгружает все в папку и запускается оттуда. Но чтобы все работало секьюрно, правильно, хорошо и в традициях 1С, вы предлагаете завести проект на React и просто перекомпилировать все в один файл? Есть ли там какие-то подводные камни?

Если вы посмотрите на репозиторий консоли BSL, там уже есть отдельная ветка, где эта сборка сделана на Webpack. Она пока не вошла в продуктив, потому что там еще не все тесты прошли. Но эта ветка уже давно живет, много людей ее тестируют. Поэтому процесс в эту сторону уже идет.

Есть ли особенности в поведении приложения, если мы подгружаем его в веб-клиент 1С с другого сайта? Я имею в виду cross-origin-запросы и связанные с ними ограничения. Мы, например, сталкивались с ситуацией, когда не удавалось подгрузить страницу даже с того же домена, хотя обычная ссылка на этот ресурс работала без проблем.

Есть две проблемы.

• Первая проблема связана с X-Frame-Options – настройкой веб-сервера, которая ограничивает возможность встраивания страниц в iframe. По умолчанию большинство серверов (Nginx, Apache, IIS и т.д.) запрещают подобное поведение, если не указано иное. В вашем случае его нужно разрешить – для этого же домена или конкретного сайта.

• А вторая проблема – это CORS (Cross-Origin Resource Sharing), политика безопасности браузера, которая тоже может блокировать загрузку ресурсов с других доменов. Чтобы разрешить такие запросы и отдавать правильный заголовок на разрешение загрузки, нужно опять же конфигурировать HTTP-сервер. Причем важно, чтобы эти заголовки отдавались именно на стороне публикации веб-клиента, а не внутри самого приложения.

Компонента, про которую вы рассказывали, уже готова к использованию в продакшене?

Я делал много разных подходов к реализации таких приложений. Эта компонента стала результатом обобщения всего опыта, накопленного на разных проектах. Так что можно смело использовать. Причем там для взаимодействия с 1С используется не просто кнопка с очередью, но и более быстрая обработка сообщений.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.