On Fri, Sep 26, 2014 at 12:18 AM, Alive <[email protected]> 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-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
