当我的应用程序加载时,我注册过滤器和角度服务.
但是过滤器试图在服务返回之前执行数据,因此我的项目集合在过滤器中咆哮.
我有一个小提琴,但我不知道你是否可以在小提琴中使用$http,因为它是一个外部资源.这是我有
Fiddle
对不起,它实际上没有用.它经历了很多.
我认为我的问题是时机.我需要过滤器等待http响应或者不要“强制”自己.
我现在得到的错误是’items is undefined’,因为这是应用过滤器的地方.
在我尝试将http调用混合到一个服务之前,我确实有这个工作.但我觉得这是有角度的方式,我“只是想遵守”.
当我的控制器触发时,它会调用获取数据：
eventApi.async().then(function () {
$scope.eventCollection = eventApi.data();
});
但在它返回之前,过滤器应用于html：
<tr ng:repeat="event in events | myEventFilter:ddlFilter |
orderBy:sort.column:sort.descending">
Fiddle
这是你更新的小提琴的一个分支,修复了一些错过的依赖项(eventApi没有注入控制器,$timeout没有注入eventApi服务).我的评论将基于以下代码：
http://jsfiddle.net/BinaryMuse/zww7e/1/
这个小提琴成功地让我们看到你发布的问题：“在你的过滤器中无法读取未定义的属性’长度’.通常,过滤器应该能够默认处理空值/未定义值.我只是修改过滤器来读取这样的东西：
return function (items,eventFilterType) {
var arrayToReturn = [];
if (items === undefined) return arrayToReturn;
// ...
}
这应该照顾你的根本问题;这个小提琴现在运行没有错误,虽然看起来不能正常工作;据我所知,这是因为你在控制器的if(live)部分设置$scope.eventCollection而不是$scope.events.进行此更改会导致数据实际显示在视图中.
但是,您可能对Angular的另一个属性感兴趣：当您使用使用$q构建的promise时,您可以将视图直接绑定到promise,并且视图会将其视为将其绑定到promise的已解析值.因此,例如,您可以执行以下操作：
// in the service
$timeout(function () {
deffered.resolve(fakeEvents); // <-- resolve with the data
},2000);
return deffered.promise;
// in the controller
if (live) {
$scope.events = eventApi.async();
}
这是演示此技术的小提琴的更新版本：http://jsfiddle.net/BinaryMuse/zww7e/2/
[更新]
正如Jeff在评论中指出的那样,Angular正在弃用自动承诺展开;你可以see the commit here,但这里是消息：
fix($parse): deprecate promise unwrapping and make it an opt-in
This commit disables promise unwrapping and adds
$parseProvider.unwrapPromises() getter/setter api that allows
developers to turn the feature back on if needed. Promise unwrapping
support will be removed from Angular in the future and this setting
only allows for enabling it during transitional period.
If the unwrapping is enabled,Angular will log a warning about each
expression that unwraps a promise (to reduce the noise,each
expression is logged only onces). To disable this logging use
$parseProvider.logPromiseWarnings(false).
Previously promises found anywhere in the expression during expression
evaluation would evaluate to undefined while unresolved and to the
fulfillment value if fulfilled.
This is a feature that didn’t prove to be wildly useful or popular,
primarily because of the dichotomy between data access in templates
(accessed as raw values) and controller code (accessed as promises).
In most code we ended up resolving promises manually in controllers or
automatically via routing and unifying the model access in this way.
Other downsides of automatic promise unwrapping:
- when building components it’s often desirable to receive the raw promises
- adds complexity and slows down expression evaluation
- makes expression code pre-generation unattractive due to the amount of code that needs to be generated
- makes IDE auto-completion and tool support hard
- adds too much magic
BREAKING CHANGE: $parse and templates in general will no longer
automatically unwrap promises. This feature has been deprecated and if
absolutely needed,it can be reenabled during transitional period via
$parseProvider.unwrapPromises(true) api.
