908826 - Don't artificially force asynchronicity when only using addResource

Status: RESOLVED WONTFIX

(L20n :: JS Library, defect)

Description

[Staś Małolepszy :stas]

When only using addResource (e.g. in build-time optimizations), we don't need to make any XHRs, and in fact the whole preparation of the context can by synchronous (nothing wrong with that).

We'll need to update a few tests.

Comment 1

[Staś Małolepszy :stas]

I'm a little bit concerned about this and about the inconsistency of the API.  Consider the following two examples:

1. linkResource (async)

var ctx = L20n.getContext();
ctx.ready(function() {
  console.log(2);
})
ctx.linkResource('./locales/strings.l20n');
ctx.requestLocales();
console.log(1)

// output:
// 1
// 2


2. addResource (sync)

var ctx = L20n.getContext();
ctx.ready(function() {
  console.log(2);
})
ctx.addResource('<foo "Foo">');
ctx.requestLocales();
console.log(1)

// output:
// 2
// 1

I'm not sure it's a good idea to surprise developers by having what boils down to a maybe-async requestLocales.

(For BTO and xpcshell, we could achieve the functionality of setTimeout via DeferredTask.jsm, Promise.jsm or directly using the thread manager (tm.jsm). The code could live in lib/xpc/l20n/platform/io.js)

Comment 2

[Staś Małolepszy :stas]

Let's keep requestLocales consistently async.