Module: Dommy::Bridge

Defined in:

lib/dommy/bridge.rb,
lib/dommy/bridge/methods.rb,
lib/dommy/bridge/constructor_registry.rb

Overview

‘Dommy::Bridge` — adapter classes for JS-style bridges (wasm embedders that route DOM method calls and constructor `new` ops through the `js_get` / `js_set` / `js_call` / `js_new` protocol).

CRuby users writing happy-dom-style tests can ignore everything in this namespace; it’s only relevant when integrating Dommy with an external runtime (such as an mruby-on-wasm host) that constructs callbacks / events / promises via the bridge view.

The protocol contract:

- `__js_get__(name)` reads a JS-style property by string name
- `__js_set__(name, value)` writes one
- `__js_call__(method, args)` invokes a method with positional
  args (Array)
- `__js_new__(args)` invokes the value as a JS constructor

Defined Under Namespace

Modules: Methods Classes: ArrayBuffer, Bytes, Callback, Constructor, ConstructorRegistry, JSValue, PromiseConstructor, PromiseSettler, RangeError, ThrowValue, TypeError

Constant Summary

UNHANDLED =

Sentinel returned by ‘js_set` when a key is not a known DOM property (so the JS host can keep it as a JS-side expando, preserving identity) rather than silently dropping it.

:__js_unhandled__

UNDEFINED =

Sentinel for the JS ‘undefined` value, used in both directions:

- a `__js_call__` returns it for a void (undefined-returning) op, so the
  host marshals JS `undefined` rather than the `null` a bare Ruby `nil`
  would (e.g. DOMTokenList add/remove return undefined);
- a top-level JS `undefined` *argument* arrives as it (whereas JS `null`
  arrives as `nil`), so WebIDL-style dispatch can tell an omitted optional
  argument from an explicit null.

Its ‘to_s` is “undefined” so a DOMString coercion of a stray undefined is still spec-faithful.

Object.new