如何扩展微风与标准CommonJS承诺规范可互操作

Question

我有猴子修补了微风EntityManager.prototype，因此它返回角$ q promises同时也调用$ rootScope。$ apply（使用类似于Ward Bell's solution的代码）。

但是，这有一个重要方面： breeze内部代码使用promise对象上的fail方法注册errorCallbacks （例如promise.then（callback）.fail（errCallback） ）

fail方法不是CommonJS promise / A +规范的一部分，因此不包含在angularjs promise api中。结果是angularjs承诺EntityManager.prototype现在返回没有fail方法，因此抛出异常。

问题：有没有一种方法可以自定义breezejs，以便只支持CommonJS / A +规范中包含的promise api，而不必直接修改breezejs库本身？由于没有怀疑，所以我也提出breeze change request。

由于 Christian Crowhurst

Answer 1

请不要使用$ q 来修补微风EntityManager原型。当你这样做时，你违反了保修条款。只是不要。

Breeze使用Q.js表示承诺，Q符合CommonJS标准。 Q是一个坚如磐石的承诺实施; $ q ...没那么多。

如果有任何问题你应该抱怨$ q不符合规范，因为它会调用$apply这是一种副作用，这通常是不受欢迎的，特别是在测试中。不要让我开始。

fail方法只是Q糖，是then的扩展。我们喜欢它的可读性，我们使用它。

  

如果您愿意，可以在$ q承诺承诺中添加fail方法。很简单。类似于then(function(data){return data;}, failHandler)

的别名

你可以假设我们不应该在内部使用Q fail方法，而是将我们在Breeze组件中使用promise限制为仅限于CommonJS规范中标识的那些成员。我会在内心提出这个想法。它肯定会促进Q的替代品的可能性。我个人不喜欢Breeze对第三方库有任何依赖性，甚至像Q一样出色的库。

相信我，我们考虑过这一点。我们无法解决一个障碍：大多数承诺实施都是废话。

Breeze依赖于一个在所有条件下都能正常运行的promise库，特别是在处理异常时。如果我们打开这扇门，人们就会开始插入他们想要的任何承诺库......任何采用“then”方法的东西。他们的Breeze应用程序将开始以神秘和不合时宜的方式打破。我们接到电话告诉我们Breeze是垃圾。

例证：jQuery。延迟的jQuery是一个破坏的实现。如果有人使用它代替Q，那么Breeze应用程序就会破解。并不是所有的时间......这比打破所有时间都要糟糕。

我不会说$q是废话。我会说这是不健全的...而不仅仅因为它总是调用（或相当于调用）$ apply。

让我再说一遍我在顶部所说的话：请不要用$ q修补微风EntityManager原型。

我可以想象为什么你想要这样做。您希望从EntityManager方法返回的承诺是$ q承诺。抱歉。馊主意。

请关注我的推荐。 Use our to$q extension to Q.js（即将出版的文件）。之后很容易“安装”，而不是：

var QPromise1 = someQuery.using(manager).execute();
var QPromise2 = anotherQuery.using(manager).execute().then(success, fail);

你写下这个：

var $qPromise1 = someQuery.using(manager).execute().to$q();
var $qPromise2 = anotherQuery.using(manager).execute().to$q(success, fail);

有多难？

Answer 2

看起来Breeze的回复（使用Breeze Labs免责声明）是：

to$q - a bridge to Angular promises

“BreezeJS异步方法返回一个promise，通常是从远程服务传递一些数据的承诺（如果服务请求失败，则返回错误）。

Breeze方法返回Q.js承诺而不是AngularJS $ q promises。 to $ q插件可以轻松地从Breeze Q承诺过渡到Angular $ q承诺。“