Creating JavaScript callbacks in components

  • Revision slug: Creating_JavaScript_callbacks_in_components
  • Revision title: Creating JavaScript callbacks in components
  • Revision id: 92836
  • Created:
  • Creator: Nickolay
  • Is current revision? No
  • Comment markup changes, add Category:XPCOM

Revision Content

Callback patterns in IDL

XPCOM components use IDL to create interfaces. These interfaces are used to manipulate the component in C++ and JavaScript. A common pattern used with interfaces to create a bi-directional communication between two groups of code is the observer (or listener) pattern. Basically, the component defines an observer (or listener) interface which is implemented by some external code and this implementation is passed to the component. The component can then call methods on the observer interface to signal the external code when predefined events occur. Here is a very simple example of the observer pattern:

[scriptable, uuid(...)]
interface StringParserObserver {
  void onWord(string word);
};

[scriptable, uuid(...)]
interface StringParser {
  void parse(string data);

  void addObserver(StringParserObserver observer);
};

In this example, the StringParser will call the StringParserObserver.onWord method whenever it finishes parsing a word found in the raw string data. Here is an example of how to use the callback system:

var wordHandler {
  onWord : function(word) {
    alert(word);
  }
};

var stringParser = /* get a reference to the parser somehow */
stringParser.addObserver(wordHandler);
stringParser.parse("pay no attention to the man behind the curtain");

You can find examples of this pattern all over the Mozilla codebase. In fact, there is even a specific interface for this form of push callbacks, nsIObserverService.

JavaScript functions as callbacks

Another common use of the pattern is found in addEventListener / removeEventListener. A nice feature of addEventListener is that you can pass a JavaScript function in place of the callback listener interface. Remember (or discover) that addEventListener is a method of the {{ Source("dom/public/idl/events/nsIDOMEventTarget.idl", "nsIDOMEventTarget") }} interface and is defined as such:

void addEventListener(in DOMString type,
                      in nsIDOMEventListener listener,
                      in boolean useCapture);

However, it is extremely common to see developers pass a normal JavaScript function for the listener instead of an {{ Source("dom/public/idl/events/nsIDOMEventListener.idl", "nsIDOMEventListener") }} implementation:

function doLoad(event) {
  // do something here
}

window.addEventListener("load", doLoad, false);

Revealing the magic

How is this possible? Is nsIDOMEventListener magical? Well, it actually is a little magical. But you can use the same magic in your own IDL callbacks. The nsIDOMEventListener interface is "marked" with the function attribute. See it {{ Source("dom/public/idl/events/nsIDOMEventListener.idl#52", "here") }}. The function attribute tells the XPConnect machinery to treat the JavaScript function as if it was an implementation of the callback interface. Note, that since the JavaScript function is a single method, this magic only works for callback interfaces with a single method, like nsIDOMEventListener. The JavaScript function is passed the same arguments as defined by the callback method.

So we could convert the example above to accept JavaScript functions in place of the StringParserObserver by making the following changes:

[scriptable, function, uuid(...)]
interface StringParserObserver {
  void onWord(string word);
};

[scriptable, uuid(...)]
interface StringParser {
  void parse(string data);

  void addObserver(StringParserObserver observer);
};

Note the only change was adding function to the interface attributes of the callback interface. Now we can create a callback JavaScript function to handle the onWord event:

function handleWord(word) {
  alert(word);
}

var stringParser = /* get a reference to the parser somehow */
stringParser.addObserver(handleWord);
stringParser.parse("pay no attention to the man behind the curtain");

Yes, you can still use the normal interface-based callback implementation too. Using JavaScript functions as callback handlers for components can be a nice convenience to developers and there is virtually zero work to expose the feature.

Revision Source

<h3 name="Callback_patterns_in_IDL">Callback patterns in IDL</h3>
<p><a href="en/XPCOM">XPCOM</a> components use IDL to create interfaces. These interfaces are used to manipulate the component in C++ and JavaScript. A common pattern used with interfaces to create a bi-directional communication between two groups of code is the <a class="external" href="http://en.wikipedia.org/wiki/Observer_pattern">observer (or listener) pattern</a>. Basically, the component defines an observer (or listener) interface which is implemented by some external code and this implementation is passed to the component. The component can then call methods on the observer interface to signal the external code when predefined events occur. Here is a very simple example of the observer pattern:
</p>
<pre>[scriptable, uuid(...)]
interface StringParserObserver {
  void onWord(string word);
};

[scriptable, uuid(...)]
interface StringParser {
  void parse(string data);

  void addObserver(StringParserObserver observer);
};
</pre>
<p>In this example, the <code>StringParser</code> will call the <code>StringParserObserver.onWord</code> method whenever it finishes parsing a word found in the raw string data. Here is an example of how to use the callback system:
</p>
<pre>var wordHandler {
  onWord : function(word) {
    alert(word);
  }
};

var stringParser = /* get a reference to the parser somehow */
stringParser.addObserver(wordHandler);
stringParser.parse("pay no attention to the man behind the curtain");
</pre>
<p>You can find examples of this pattern all over the Mozilla codebase. In fact, there is even a specific interface for this form of push callbacks, <a href="en/NsIObserverService">nsIObserverService</a>.
</p>
<h3 name="JavaScript_functions_as_callbacks">JavaScript functions as callbacks</h3>
<p>Another common use of the pattern is found in <code><a href="en/DOM/element.addEventListener">addEventListener</a></code> / <code><a href="en/DOM/element.removeEventListener">removeEventListener</a></code>. A nice feature of <code>addEventListener</code> is that you can pass a JavaScript function in place of the callback listener interface. Remember (or discover) that <code>addEventListener</code> is a method of the <code>{{ Source("dom/public/idl/events/nsIDOMEventTarget.idl", "nsIDOMEventTarget") }}</code> interface and is defined as such:
</p>
<pre class="eval">void addEventListener(in DOMString type,
                      in <b>nsIDOMEventListener listener</b>,
                      in boolean useCapture);
</pre>
<p>However, it is extremely common to see developers pass a normal JavaScript function for the listener instead of an <code>{{ Source("dom/public/idl/events/nsIDOMEventListener.idl", "nsIDOMEventListener") }}</code> implementation:
</p>
<pre>function doLoad(event) {
  // do something here
}

window.addEventListener("load", doLoad, false);
</pre>
<h3 name="Revealing_the_magic">Revealing the magic</h3>
<p>How is this possible? Is <code>nsIDOMEventListener</code> magical? Well, it actually is a little magical. But you can use the same magic in your own IDL callbacks. The <code>nsIDOMEventListener</code> interface is "marked" with the <code>function</code> attribute. See it {{ Source("dom/public/idl/events/nsIDOMEventListener.idl#52", "here") }}. The <code>function</code> attribute tells the XPConnect machinery to treat the JavaScript function as if it was an implementation of the callback interface. Note, that since the JavaScript function is a single method, this magic only works for callback interfaces with a single method, like <code>nsIDOMEventListener</code>. The JavaScript function is passed the same arguments as defined by the callback method.
</p><p>So we could convert the example above to accept JavaScript functions in place of the <code>StringParserObserver</code> by making the following changes:
</p>
<pre class="eval">[scriptable, <b>function, </b>uuid(...)]
interface StringParserObserver {
  void onWord(string word);
};

[scriptable, uuid(...)]
interface StringParser {
  void parse(string data);

  void addObserver(StringParserObserver observer);
};
</pre>
<p>Note the only change was adding <code>function</code> to the interface attributes of the callback interface. Now we can create a callback JavaScript function to handle the <code>onWord</code> event:
</p>
<pre>function handleWord(word) {
  alert(word);
}

var stringParser = /* get a reference to the parser somehow */
stringParser.addObserver(handleWord);
stringParser.parse("pay no attention to the man behind the curtain");
</pre>
<p>Yes, you can still use the normal interface-based callback implementation too. Using JavaScript functions as callback handlers for components can be a nice convenience to developers and there is virtually zero work to expose the feature.
</p>
Revert to this revision