This document is a subset of the Mojo documentation.
The bindings API is defined in the mojo
namespace and implemented in mojo_bindings.js
, which could be generated by the GN target //mojo/public/js:bindings
.
When a Mojom IDL file is processed by the bindings generator, JavaScript code is emitted in a .js
file with the name based on the input .mojom
file. Suppose we create the following Mojom file at //services/echo/public/interfaces/echo.mojom
:
module test.echo.mojom; interface Echo { EchoInteger(int32 value) => (int32 result); };
And a GN target to generate the bindings in //services/echo/public/interfaces/BUILD.gn
:
import("//mojo/public/tools/bindings/mojom.gni") mojom("interfaces") { sources = [ "echo.mojom", ] }
Bindings are generated by building one of these implicitly generated targets (where “foo” is the target name):
foo_js
JavaScript bindings; used as compile-time dependency.foo_js_data_deps
JavaScript bindings; used as run-time dependency.If we then build this target:
ninja -C out/r services/echo/public/interfaces:interfaces_js
This will produce several generated source files. The one relevant to JavaScript bindings is:
out/gen/services/echo/public/interfaces/echo.mojom.js
In order to use the definitions in echo.mojom
, you will need to include two files in your html page using <script>
tags:
mojo_bindings.js
Note: This file must be included before any .mojom.js
files.echo.mojom.js
<!DOCTYPE html> <script src="URL/to/mojo_bindings.js"></script> <script src="URL/to/echo.mojom.js"></script> <script> var echoPtr = new test.echo.mojom.EchoPtr(); var echoRequest = mojo.makeRequest(echoPtr); // ... </script>
Similar to the C++ bindings API, we have:
mojo.InterfacePtrInfo
and mojo.InterfaceRequest
encapsulate two ends of a message pipe. They represent the client end and service end of an interface connection, respectively.Foo
, there is a generated FooPtr
class. It owns an InterfacePtrInfo
; provides methods to send interface calls using the message pipe handle from the InterfacePtrInfo
.mojo.Binding
owns an InterfaceRequest
. It listens on the message pipe handle and dispatches incoming messages to a user-defined interface implementation.Let's consider the echo.mojom
example above. The following shows how to create an Echo
interface connection and use it to make a call.
<!DOCTYPE html> <script src="URL/to/mojo_bindings.js"></script> <script src="URL/to/echo.mojom.js"></script> <script> function EchoImpl() {} EchoImpl.prototype.echoInteger = function(value) { return Promise.resolve({result: value}); }; var echoServicePtr = new test.echo.mojom.EchoPtr(); var echoServiceRequest = mojo.makeRequest(echoServicePtr); var echoServiceBinding = new mojo.Binding(test.echo.mojom.Echo, new EchoImpl(), echoServiceRequest); echoServicePtr.echoInteger({value: 123}).then(function(response) { console.log('The result is ' + response.value); }); </script>
In the example above, test.echo.mojom.EchoPtr
is an interface pointer class. EchoPtr
represents the client end of an interface connection. For method EchoInteger
in the Echo
Mojom interface, there is a corresponding echoInteger
method defined in EchoPtr
. (Please note that the format of the generated method name is camelCaseWithLowerInitial
.)
There are some control methods shared by all interface pointer classes. For example, binding/extracting InterfacePtrInfo
, setting connection error handler, querying version information, etc. In order to avoid name collision, they are defined in mojo.InterfacePtrController
and exposed as the ptr
field of every interface pointer class.
In the example above, echoServiceRequest
is an InterfaceRequest
instance. It represents the service end of an interface connection.
mojo.makeRequest
creates a message pipe; populates the output argument (which could be an InterfacePtrInfo
or an interface pointer) with one end of the pipe; returns the other end wrapped in an InterfaceRequest
instance.
A mojo.Binding
bridges an implementation of an interface and a message pipe endpoint, dispatching incoming messages to the implementation.
In the example above, echoServiceBinding
listens for incoming EchoInteger
method calls on the messsage pipe, and dispatches those calls to the EchoImpl
instance.
Some Mojom interface methods expect a response, such as EchoInteger
. The corresponding JavaScript method returns a Promise. This Promise is resolved when the service side sends back a response. It is rejected if the interface is disconnected.
If a pipe is disconnected, both endpoints will be able to observe the connection error (unless the disconnection is caused by closing/destroying an endpoint, in which case that endpoint won‘t get such a notification). If there are remaining incoming messages for an endpoint on disconnection, the connection error won’t be triggered until the messages are drained.
Pipe disconnecition may be caused by:
Regardless of the underlying cause, when a connection error is encountered on a binding endpoint, that endpoint's connection error handler (if set) is invoked. This handler may only be invoked once as long as the endpoint is bound to the same pipe. Typically clients and implementations use this handler to do some kind of cleanup or recovery.
// Assume echoServicePtr is already bound. echoServicePtr.ptr.setConnectionErrorHandler(function() { DoImportantCleanUp(); }); // Assume echoServiceBinding is already bound: echoServiceBinding.setConnectionErrorHandler(function() { DoImportantCleanUpToo(); });
Note: Closing one end of a pipe will eventually trigger a connection error on the other end. However it's ordered with respect to any other event (e.g. writing a message) on the pipe. Therefore, it is safe to make an echoInteger
call on echoServicePtr
and reset it immediately (which results in disconnection), echoServiceBinding
will receive the echoInteger
call before it observes the connection error.
An associated interface connection doesn't have its own underlying message pipe. It is associated with an existing message pipe (i.e., interface connection).
Similar to the non-associated interface case, we have:
mojo.AssociatedInterfacePtrInfo
and mojo.AssociatedInterfaceRequest
encapsulate a route ID, representing a logical connection over a message pipe.Foo
, there is a generated FooAssociatedPtr
class. It owns an AssociatedInterfacePtrInfo
. It is the client side of an interface.mojo.AssociatedBinding
owns an AssociatedInterfaceRequest
. It listens on the connection and dispatches incoming messages to a user-defined interface implementation.See this document for more details.
By default, generated .mojom.js
files automatically load Mojom dependencies. For example, if foo.mojom
imports bar.mojom
, loading foo.mojom.js
will insert a <script>
tag to load bar.mojom.js
, if it hasn't been loaded.
The URL of bar.mojom.js
is determined by:
bar.mojom
relative to the position of foo.mojom
at build time;foo.mojom.js
.For exmple, if at build time the two Mojom files are located at:
a/b/c/foo.mojom a/b/d/bar.mojom
The URL of foo.mojom.js
is:
http://example.org/scripts/b/c/foo.mojom.js
Then the URL of bar.mojom.js
is supposed to be:
http://example.org/scripts/b/d/bar.mojom.js
If you would like bar.mojom.js
to live at a different location, you need to set mojo.config.autoLoadMojomDeps
to false
before loading foo.mojom.js
, and manually load bar.mojom.js
yourself. Similarly, you need to turn off this option if you merge bar.mojom.js
and foo.mojom.js
into a single file.
<!-- Automatic dependency loading --> <script src="http://example.org/scripts/mojo_bindings.js"></script> <script src="http://example.org/scripts/b/c/foo.mojom.js"></script> <!-- Manual dependency loading --> <script src="http://example.org/scripts/mojo_bindings.js"></script> <script> mojo.config.autoLoadMojomDeps = false; </script> <script src="http://example.org/scripts/b/d/bar.mojom.js"></script> <script src="http://example.org/scripts/b/c/foo.mojom.js"></script>
If mojo.config.autoLoadMojomDeps
is set to true
(which is the default value), you might accidentally load the same .mojom.js
file multiple times if you are not careful. Although it doesn't cause fatal errors, it hurts performance and therefore should be avoided.
<!-- Assume that mojo.config.autoLoadMojomDeps is set to true: --> <!-- No duplicate loading; recommended. --> <script src="http://example.org/scripts/b/c/foo.mojom.js"></script> <!-- No duplicate loading, although unnecessary. --> <script src="http://example.org/scripts/b/d/bar.mojom.js"></script> <script src="http://example.org/scripts/b/c/foo.mojom.js"></script> <!-- Load bar.mojom.js twice; should be avoided. --> <!-- when foo.mojom.js is loaded, it sees that bar.mojom.js is not yet loaded, so it inserts another <script> tag for bar.mojom.js. --> <script src="http://example.org/scripts/b/c/foo.mojom.js"></script> <script src="http://example.org/scripts/b/d/bar.mojom.js"></script>
If a .mojom.js
file is loaded for a second time, a warnings will be showed using console.warn()
to bring it to developers' attention.
As a general rule, Mojom definitions follow the C++ formatting style. To make the generated JavaScript bindings conforms to our JavaScript style guide, the code generator does the following conversions:
In Mojom | In generated .mojom.js |
---|---|
MethodLikeThis | methodLikeThis |
parameter_like_this | parameterLikeThis |
field_like_this | fieldLikeThis |
name_space.like_this | nameSpace.likeThis |