Mojo JS: Attempt to simplify bindTo* related code.

chrome/browser/resources/plugins.js

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 /**
  * Takes the |pluginsData| input argument which represents data about the
  * currently installed/running plugins and populates the html jstemplate with
  * that data.
  * @param {Object} pluginsData Detailed info about installed plugins. Same
  *     expected format as returnPluginsData().
@@ skipping 245 matching lines @@
  * @return {!Promise}
  */
 function importModules(moduleNames) {
   return new Promise(function(resolve, reject) {
     define(moduleNames, function(var_args) {
       resolve(Array.prototype.slice.call(arguments, 0));
     });
   });
 }
 
-// NOTE: Need to keep a reference to the stub here such that it is not garbage
-// collected, which causes the pipe to close and future calls from C++ to JS to
-// get dropped.
-var pluginsPageStub = null;
-
+// NOTE: Need to keep a global reference to the |pageProxy| such that it is not
+// garbage collected, which causes the pipe to close and future calls from C++
+// to JS to get dropped. This also allows tests to make direct calls on it.
+var pageProxy = null;
 var browserProxy = null;
-// Exposed globally such that the tests can make direct calls on it.
-var pageProxy = null;
 
 function initializeProxies() {
   return importModules([
     'mojo/public/js/bindings',
     'mojo/public/js/core',
     'mojo/public/js/connection',
     'chrome/browser/ui/webui/plugins/plugins.mojom',
     'content/public/renderer/frame_service_registry',
   ]).then(function(modules) {
     var bindings = modules[0];
     var core = modules[1];
     var connection = modules[2];
     var pluginsMojom = modules[3];
     var serviceProvider = modules[4];
 
     browserProxy = connection.bindHandleToProxy(
         serviceProvider.connectToService(pluginsMojom.PluginsPageHandler.name),
         pluginsMojom.PluginsPageHandler);
 
-    // Connect pipe handle to JS code.
-    var pipe = core.createMessagePipe();
-    pluginsPageStub = connection.bindHandleToStub(
-        pipe.handle0, pluginsMojom.PluginsPage);
+    /** @constructor */
+    var PluginsPageProxy = function() {};
 
-    pageProxy = {
+    PluginsPageProxy.prototype = {
       __proto__: pluginsMojom.PluginsPage.stubClass.prototype,
+
+      /** @override */
       onPluginsUpdated: function(plugins) {
         returnPluginsData({plugins: plugins});
       },
     };
+    pageProxy = new PluginsPageProxy();
 
-    bindings.StubBindings(pluginsPageStub).delegate = pageProxy;
-    // Send pipe handle to C++.
+    var pipe = core.createMessagePipe();
+    // Connect one end of the pipe to JS.
+    connection.bindHandleToObj(pipe.handle0, pageProxy);

[yzshen1, 2016/05/27 16:24:45]

Does it make sense to name it bindHandleToImpl()?
Impl indicates that this is the implementation side of an interface. Obj seems a
little vague.

PluginsPageProxy should probably be named PluginsPageImpl. "Proxy" usually used
for the caller side of an interface.

[dpapad, 2016/05/27 17:55:37]

I found a way to simplify even more by completely hiding the pipe creation, and
simply exposing (returning) the end of the pipe that needs to be sent to C++.
This makes the client code simpler
1) No need to create message pipe.
2) New method only receives one parameter, the implementation object.
3) Client code no longer needs to depend directly on the Mojo "core" module, it
was only needed to call core.createMessagePipe.

Regarding the naming "pageProxy" I prefer to keep it as-is for two reasons.
1) Even though the "pageProxy" object is not residing on the caller side, it
still acts as a proxy since it is an intermediate to execute methods on the page
(see how PluginsPageProxy#onPluginsUpdated calls  returnPluginsData). In other
words, I am considering "returnPluginsData" (and all other global methods in
plugins.js) as the real implementation, and |pageProxy| as an intermediate
object.

2) From the test's point of view, which simulates incoming calls from the
browser, pageProxy matches exactly your expectation (caller side of an
interface), see
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/test/data/w....

[yzshen1, 2016/05/27 18:32:46]

Okay. I am fine with any name that seems appropriate to the domain experts like
you. :) Just saying that it feel counter-intuitive to me since "Proxy" has a
specific meaning in the JS bindings.

[dpapad, 2016/05/27 20:36:56]

Ended up renaming to PluginsPageImpl per your suggestion, to be more consistent
with the usage of the "term" proxy withing JS bindings terminology
(bindings.js).

+    // Send the other end of the pipe to C++.
     browserProxy.setClientPage(pipe.handle1);
   });
 }
 
 /**
  * Overriden by tests to give them a chance to setup a fake Mojo browser proxy
  * before any other code executes.
  * @return {!Promise} A promise firing once necessary setup has been completed.
  */
 var setupFn = setupFn || function() { return Promise.resolve(); };
@@ skipping 17 matching lines @@
 
     // Unfortunately, we don't have notifications for plugin (list) status
     // changes (yet), so in the meanwhile just update regularly.
     setInterval(function() {
       browserProxy.getPluginsData().then(returnPluginsData);
     }, 30000);
   });
 }
 
 document.addEventListener('DOMContentLoaded', main);