WASM доступ DOM
Есть ли способ получить доступ на чтение / запись к DOM и / или к WebAPI (то есть к полноэкранному API) без JavaScript?
Я пытаюсь создать базовое приложение на C(источник C на самом деле является результатом переноса с языка GC). Приложение, которое я создаю, будет работать как приложение для настольных компьютеров (пока оно не предназначено для работы в "настоящих" браузерах), поэтому я могу при необходимости настроить среду (то есть механизм компоновки).
2 ответа
В минимально жизнеспособном продукте WebAssembly единственный способ вызывать и выводить WebAssembly через импорт и экспорт. В будущем WebAssembly может получить возможности, которые позволяют встраиваемому устройству напрямую представлять API-интерфейсы, а встраивание в браузер может включать DOM.
Импорт и экспорт не очень сложны: с точки зрения вашего кода на C они просто выглядят как extern вызов, похожий на DLL на платформе Windows. Скорее всего, вы скомпилируете код C с использованием Emscripten, смотрите его документацию "Вызов функций JavaScript из C/C++", чтобы узнать, как это работает (поскольку это не тот вопрос, который вы задаете, но я полагаю, что следующий вопрос).
Из вашего вопроса не ясно, если вы:
- Хотите скомпилировать код C и запустить его в WebAssembly внутри браузера.
- Хотите скомпилировать код C и запустить его в WebAssembly вне браузера.
Или оба.
Все зависит от возможностей компилятора.
В настоящее время нет прямого доступа к DOM или любому другому API браузера. Также невозможно хранить ссылки JavaScript внутри линейной памяти Wasm или таблиц Wasm. Также невозможно использовать ссылки JavaScript в качестве аргументов функции или возвращаемых значений. Они просто не существуют в системе типов MVP. Тем не менее, существует предложение типа ссылки, которое может когда-нибудь стать частью среды выполнения Wasm, но официальной даты выпуска пока нет.
Итак, как можно взаимодействовать с Wasm to Host? Что ж, получается, что модульную систему Wasm с импортом и экспортом можно использовать для создания слоя эмуляции. Создание этого слоя вручную является болезненным, поэтому компилятору полезно создать его. Но как?
Например, мы хотим установить заголовок документа в текущем окне браузера. Wasm должен получить доступ к текущему экземпляру окна, выбрать документ и установить его свойство title. Поскольку среда выполнения Wasm не может получить доступ к ссылкам, нам нужно создать таблицу сопоставления на стороне JS и некоторые функции JS с логикой сопоставления и импортировать их в модуль Wasm.
Итак, мы создаем функцию с именем getWindow. Эта функция берет глобальную ссылку на окно, помещает ее в таблицу сопоставления и возвращает индекс в таблице. Этот индекс будет доступен как I32 на стороне Wasm. Эта функция импортируется в модуль Wasm.
Теперь мы создаем функцию с именем getDocumentFromWindow. Эта функция берет индекс в таблицу сопоставления и возвращает другой индекс. Реализация ищет ссылку на окно из таблицы сопоставления и разрешает его свойство документа, помещает этот документ в таблицу сопоставления и возвращает этот индекс в Wasm. Эта функция также импортируется в модуль Wasm.
Что касается Wasm, то теперь мы можем косвенно манипулировать ссылками на хост Wasm нашими импортированными функциями. Наша таблица сопоставления эмулирует ссылки JS целочисленными индексами. Это более медленная версия того, что может прийти с предложением Wasm Reference Type.
Таким образом, вся эта логика отображения может быть создана компилятором. Как только ссылочные типы станут доступны, можно изменить компилятор и использовать новую систему типов для более эффективного кода.
Если вы хотите увидеть такой вид, если компилятор в действии, посмотрите https://github.com/mirkosertic/Bytecoder. Он может компилировать байт-код JVM в JavaScript и WebAssembly и обеспечивает прозрачный способ взаимодействия DOM и API браузера обоими способами. Можно вызвать DOM из Wasm, а также можно вызвать Wasm из DOM, например, для реализации прослушивателей кликов и других интересных вещей, таких как взаимодействие с высокоуровневыми фреймворками, такими как vue.js.
Отказ от ответственности: я изобретатель Bytecoder, но описанную логику можно адаптировать к любому другому компилятору.
Люди WebAssembly пока не имеют четкого представления о том, как будут выглядеть объекты JS в WebAssembly.
Я бы посмотрел PR # 1080, который о том, что спецификация Сборки мусора пока выдвигается в его собственное репо. Но пока это происходит, они удаляют только упоминания о веб-платформе и взаимодействуют с объектами JS, существующими в спецификации, которая описывается как:
It's more aspirational that concrete,
Я только что наткнулся на js_ffi
https://github.com/richardanaya/js_ffi
Не уверен, работает ли он и для C, но он рекламируется как таковой.