DevTools/Actor Best Practices: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Remove disconnect vs. destroy after bug 1315391)
Line 1: Line 1:
Some aspects of front and actor design can be tricky to understand, even for experienced engineers.  The following are several best practices you should keep in mind when adding new actors and fronts.
Some aspects of front and actor design can be tricky to understand, even for experienced engineers.  The following are several best practices you should keep in mind when adding new actors and fronts.


== Actor should clean up itself, don't wait for the client ==
== Actor Should Clean Up Itself, Don't Wait For the Client ==


In the past, some actors would wait for the client to send a "you are done now" message when the toolbox closes to shutdown the actor.  This seems reasonable at first, but keep in mind that the connection can disappear at any moment.  It may not be possible for the client to send this message.
In the past, some actors would wait for the client to send a "you are done now" message when the toolbox closes to shutdown the actor.  This seems reasonable at first, but keep in mind that the connection can disappear at any moment.  It may not be possible for the client to send this message.
Line 7: Line 7:
A better choice is for the actor to do all clean up itself when it's notified that the connection goes away.  Then there's no need for the client to send any clean up message, and we know the actor will be in a good state no matter what.
A better choice is for the actor to do all clean up itself when it's notified that the connection goes away.  Then there's no need for the client to send any clean up message, and we know the actor will be in a good state no matter what.


For actors that are the first to be managed by protocol.js in an actor tree (this applies to anything that is a child of the root actor which you would add to server/main.js), you can do this by implementing your actor's <code>disconnect</code> method:
== Actor Destruction ==


<nowiki>
Ensure that the actor's <code>destroy</code> is really destroying everything that it should.  Here's an example from the animation actor:
  disconnect: function() {
    this.destroy();
  },</nowiki>
 
Also, ensure that the actor's <code>destroy</code> is really destroying everything that it should.  Here's an example from the animation actor:


  <nowiki>
  <nowiki>

Revision as of 02:42, 16 November 2016

Some aspects of front and actor design can be tricky to understand, even for experienced engineers. The following are several best practices you should keep in mind when adding new actors and fronts.

Actor Should Clean Up Itself, Don't Wait For the Client

In the past, some actors would wait for the client to send a "you are done now" message when the toolbox closes to shutdown the actor. This seems reasonable at first, but keep in mind that the connection can disappear at any moment. It may not be possible for the client to send this message.

A better choice is for the actor to do all clean up itself when it's notified that the connection goes away. Then there's no need for the client to send any clean up message, and we know the actor will be in a good state no matter what.

Actor Destruction

Ensure that the actor's destroy is really destroying everything that it should. Here's an example from the animation actor:

  destroy: function() {
    Actor.prototype.destroy.call(this);
    events.off(this.tabActor, "will-navigate", this.onWillNavigate);
    events.off(this.tabActor, "navigate", this.onNavigate);

    this.stopAnimationPlayerUpdates();
    this.tabActor = this.observer = this.actors = null;
  },

With protocol.js actors, if your creates child actors for further functionality, in most cases you should call:

this.manage(child);

in the parent after constructing the child, so that the child is destroyed when the parent is.