本地主机与部署的角度承诺差异
Angular promise difference localhost vs deployed
我正在调用一个REST服务,该服务返回true或false。
function topLevelClosed($stateParams) {
var id = $stateParams.id;
return id ? Traject.topLevelClosed({id: id}).$promise : false;
}
var topLevelClosed = {
method: 'GET',
url: trajectURL + ':id/topLevelClosed'
};
topLevelClosed是$resource方法。这非常适用于localhost。topLevelClosed变量为"false",它等于REST调用返回的值。然而,当部署(到谷歌应用引擎)时,我得到的结果"被承诺包裹",如下图所示。然而,当我通过browserwindow调用REST服务时,它会返回false。
部署时的承诺结果
localhost 上的promise结果
为什么部署后不起作用?
您描述的行为正是我对这段代码的期望。当你的函数返回一个承诺时,你的调用看起来像这个
topLevelClosed($stateParams).then(function(value){
/* do something with value */
});
如果topLevelClosed返回布尔值,则可以直接访问该值而不使用then(...)
。
为了获得一致的行为,我总是会返回一个承诺,比如:
function topLevelClosed($stateParams) {
var deferred = $q.defer();
if(id){
Traject.topLevelClosed({id: id}).$promise.then(function(value){
deferred.resolve(value);
});
} else {
deferred.resolve(false);
}
return $q.promise;
}
这并没有我希望的那么漂亮,但你可以改进它。不过,我建议你总是使用一致的返回类型。当混合布尔值和promise时,在继续之前必须分析返回值的类型。
相关文章:
- 我的职位回报太快了,如何做出承诺
- 打破承诺链的好方法是什么
- chrome扩展更改主机/域警告
- 从函数返回角度承诺
- 我怎样才能获得承诺的价值
- 延期承诺值未更新/解析/延期
- 在承诺链中处理早期回报的最佳方式
- 承诺在非节点式回调上使用Bluebird
- 简单的ES6承诺问题-交换解决和拒绝参数
- 组合承诺和非承诺值
- 带有对象/原型的链式承诺(Q延期)
- 本地主机Typekit JS
- AngularJS$q承诺使用socket.io
- React JS:未捕获(在承诺中)语法错误:在位置 0 的 JSON 中意外<令牌
- 当一些承诺失败时,如何继续使用$q.all()
- Meteor应用程序无法运行-对象#<编译器>没有方法'主机'
- Nodejs和express路由,如何处理客户端的承诺
- 如何在多承诺链中处理谷歌地图API V3事件
- 承诺合并流
- 本地主机与部署的角度承诺差异