这是“延迟反模式"吗? [英] Is this a "Deferred Antipattern"?

问题描述

我发现很难理解延迟反模式".我想我基本上理解它，但我还没有看到一个关于什么是服务的超级简单示例，具有不同的承诺和反模式，所以我想我会尝试制作自己的，但看看我是怎么做的超级了解它，我会先得到一些澄清.

我在工厂(SomeFactory)中有以下内容:

//url = 'data.json';返回 {获取数据:函数(){var deferred = $q.defer();$http.get(destinationFactory.url).then(功能(响应){if (typeof response.data === 'object') {deferred.resolve(response.data);} 别的 {return deferred.reject(response.data);}}).catch(函数(错误){deferred.reject(error);});返回 deferred.promise;}

我检查它的对象的原因只是在 $http.get()

上添加一个简单的验证层

以下，在我的指令中:

this.var = SomeFactory.getData().then(功能(响应){//一些变量=响应；}).catch(函数(响应){//这里做错误处理});

据我所知，这是一个反模式.因为最初的延迟承诺捕获了错误并简单地将其吞下.它不会返回错误，所以当这个getData"方法被调用时，我做了另一个捕获来获取错误.

如果这不是反模式，那么有人可以解释为什么两者都需要某种回调"?当我第一次开始编写这个工厂/指令时，我预计必须在某处做一个延迟的承诺，但我没想到必须在双方都.catch()(也就是说，我有点想我可以如果我执行了 SomeFactory.getData()

，让工厂返回响应或错误

解决方案

这是延迟反模式"吗?

是的，是的.'Deferred anti-pattern' 当一个新的冗余 deferred 对象被创建以从 promise 链内部解析时发生.在您的情况下，您使用 $q 为隐式返回承诺的内容返回承诺.你已经有一个 Promise 对象($http service 本身返回一个 promise)，所以你只需要返回它！

这是一个超级简单的服务示例，具有延迟承诺和反模式，

<块引用>

这是反模式

app.factory("SomeFactory",['$http','$q']){返回 {获取数据:函数(){var deferred = $q.defer();$http.get(destinationFactory.url).then(功能(响应){deferred.resolve(response.data);}).catch(函数(错误){deferred.reject(error);});返回 deferred.promise;}}}])

这是你应该做的

app.factory("SomeFactory",['$http']){返回 {获取数据:函数(){//$http 本身返回一个promise返回 $http.get(destinationFactory.url);}}

虽然它们都以相同的方式消耗.

this.var = SomeFactory.getData().then(功能(响应){//一些变量=响应；}，功能(响应){//这里做错误处理});

这两个例子都没有问题(至少在语法上)..但第一个是多余的..而且不需要！

希望有帮助:)

I'm finding it hard to understand the "deferred antipattern". I think I understand it in principal but I haven't seen a super simple example of what a service, with a differed promise and one with antipattern, so I figured I'd try and make my own but seeing as how I'm not super in the know about it I'd get some clarification first.

I have the below in a factory (SomeFactory):

//url = 'data.json';

return {
    getData: function(){
        var deferred = $q.defer();

        $http.get(destinationFactory.url)
            .then(function (response) {

                if (typeof response.data === 'object') {
                    deferred.resolve(response.data);
                } else {
                    return deferred.reject(response.data);
                }
            })

            .catch(function (error) {
            deferred.reject(error);
        });

        return deferred.promise;
    }

The reason I am checking its an object is just to add a simple layer of validation onto the $http.get()

And below, in my directive:

this.var = SomeFactory.getData()
    .then(function(response) {
        //some variable = response;
    })
    .catch(function(response) {
        //Do error handling here
});

Now to my uderstanding, this is an antipattern. Because the original deferred promise catches the error and simply swallows it. It doesn't return the error so when this "getData" method is called I have do another catch to grab the error.

If this is NOT an antipattern, then can someone explain why both require a "callback" of sorts? When I first started writing this factory/directive I anticipated having to do a deffered promise somewhere, but I didn't anticipate having to .catch() on both sides (aka I was sort of thinking I could get the factory to return the response or the error if I did a SomeFactory.getData()

解决方案

Is this a "Deferred Antipattern"?

Yes, it is. 'Deferred anti-pattern' happens when a new redundant deferred object is created to be resolved from inside a promise chain. In your case you are using $q to return a promise for something that implicitly returns a promise. You already have a Promise object($http service itself returns a promise), so you just need to return it!

Here's the super simple example of what a service, with a deferred promise and one with antipattern look like,

This is anti-pattern

app.factory("SomeFactory",['$http','$q']){
    return {
        getData: function(){
            var deferred = $q.defer();            
            $http.get(destinationFactory.url)
              .then(function (response) {        
                 deferred.resolve(response.data);
            })
              .catch(function (error) {
                deferred.reject(error);
            });            
            return deferred.promise;
        }
     }
}])

This is what you should do

app.factory("SomeFactory",['$http']){
    return {
        getData: function(){
           //$http itself returns a promise 
            return $http.get(destinationFactory.url);
        }
}

while both of them are consumed in the same way.

this.var = SomeFactory.getData()
    .then(function(response) {
        //some variable = response;
    },function(response) {
        //Do error handling here
});

There's nothing wrong with either examples(atleast syntactically)..but first one is redundant..and not needed!

Hope it helps :)

这篇关于这是“延迟反模式"吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！