I'll speak to the pattern you've mentioned, as it's something I've been wanting
to address for a while. I'm not a fan of the multiple
`window.addEventListener(name, this)` pattern in their raw state as the
`handleEvent` method often becomes a conglomerate of cases. To me this is a
violation of separation of concerns and single responsibility principle. On the
other hand, having too many `.bind` calls is inefficient as they would each
technically generate a duplicate function for handling the invocation of the
bound context. Said simpler, using bind creates an additional function,
increasing overhead.
Although we don't have a unified framework for simplifying this issue, there
are patterns and conventions that would make this easier, albeit at the
tradeoff of their own smaller overhead, as an example:
```js
function Ctor() {
Ctor.events.forEach( event => window.addEventListener(event, this['handle_' +
event]) );
}
Ctor.events = ['a', 'b', 'c'];
Ctor.prototype.handle_a = function() {};
Ctor.prototype.handle_b = function() {};
Ctor.prototype.handle_c = function() {};
```
Obviously this pattern can be modified a number of different ways to suit the
preferences of author, but I think something like this is the best solution for
having proper separation of concerns and single responsibility, improved
readability, as well as having a low overhead. Granted, having access to a
standardized Finite State Machine would be much more robust, but that's neither
here nor there. :)
I'd welcome the opportunity to discuss this further.
Thanks,
Eli Perelman
Software Engineer - Firefox OS
On Friday, Sep 26, 2014 at 4:21 PM, Jonas Sicking <[email protected]>, wrote:
On Fri, Sep 26, 2014 at 12:18 AM, Alive wrote:
> Hi folks,
>
> During the cleanup work of gaia system app[1], I found that nearly every
> module inside system app (and so many other apps),
> is using a shared library called SettingsListener[2] to help it deal with
> read/write/observe settings. This is nothing wrong, but actually I/we need
> more.
>
> As I am a big fan to event listener interface and frequently use this
> pattern:
>
> ```js
> var A = {
> init: function() {
> window.addEventListener('enabled', this);
> window.addEventListener('locked', this);
> }
> handleEvent: function(evt) {
> }
> };
> A.init();
> ```
> |addEventListener| is possible to adopt an object or a function in its 2nd
> argument,
> but our mozSettings.addObserver can only adopt function..why? We have this
> pattern in gecko code base![3]
> If we could use the same or similar pattern for observing a settings change
> it'd be great!
>
> ```js
> var B = {
> init: function() {
> mozSettings.addObserver('lockscreen.enabled', this);
> mozSettings.addObserver('lockscreen.locked', this);
> },
> observe: function(topic, value) {
> }
> };
> B.init();
> ```
I'd like to hear what other people think here.
Almost all of the feedback that we've gotten elsewhere is that the
above is not a popular pattern. Instead people do things like
var C = {
init: function() {
window.addEventListener('enabled', this.handler.bind(this));
window.addEventListener('locked', this.handler.bind(this));
}
handler: function(evt) {
}
};
C.init();
This requires somewhat more typing, but has the advantage that you can
choose any function to be your callback function. It is also more
explicit and doesn't require knowing that 'observe' or 'handleEvent'
are special function names.
But again, I'd really like to get other people's input here.
> Also currently mozSettings.createLock().get()/set() doesn't smell nice. A
> promise is something developer wants.
> It'd be nice if we have read/write without creating a lock and maintain on
> our own.[4]
> ```js
> mozSettings.read('lockscreen.enabled').then(function(value) {});
> ```
This I completely agree with. The createLock() function provides
transactional protection, but I suspect that's not something we really
need for settings. That was my bad idea.
And yes, we should definitely switch from using DOMRequest to using
Promises. I think we can actually do this as a two-step process.
1. Add a .then() function to DOMRequest. This will magically make all
DOMRequests also work as promises. While still maintaining backwards
compatibility so that we don't have to rewrite all existing code at
once.
2. At whatever pace we think is appropriate, change our APIs to return
Promises rather than a DOMRequests.
Step 1 is actually fairly easy and would mean that gaia developers
could immediately start using Promise syntax anywhere where we use
DOMRequests right now.
/ Jonas
_______________________________________________
dev-gaia mailing list
[email protected]
https://lists.mozilla.org/listinfo/[email protected]>_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
