Tôi đã viết mã làm một cái gì đó trông giống như:

function getStuffDone(param) {           | function getStuffDone(param) {
    var d = Q.defer(); /* or $q.defer */ |     return new Promise(function(resolve, reject) {
    // or = new $.Deferred() etc.        |     // using a promise constructor
    myPromiseFn(param+1)                 |         myPromiseFn(param+1)
    .then(function(val) { /* or .done */ |         .then(function(val) {
        d.resolve(val);                  |             resolve(val);
    }).catch(function(err) { /* .fail */ |         }).catch(function(err) {
        d.reject(err);                   |             reject(err);
    });                                  |         });
    return d.promise; /* or promise() */ |     });
}                                        | }

Có người nói với tôi cái này được gọi là " antipotype " hoặc " Promiseantipotype " tương ứng, cái gì xấu về mã này và tại sao cái này được gọi là antipotype ?

Các antipattern hoãn lại (bây giờ rõ ràng-xây dựng antipattern) đặt ra bởi Esailija là một dân tộc antipattern chung người chưa quen với những lời hứa thực hiện, tôi đã thực hiện nó bản thân mình khi tôi lần đầu tiên sử dụng những lời hứa. Vấn đề với mã trên là thất bại trong việc sử dụng chuỗi hứa hẹn.

Lời hứa có thể xâu chuỗi .thenvà bạn có thể trả lại lời hứa trực tiếp. Mã của bạn getStuffDonecó thể được viết lại thành:

function getStuffDone(param){
    return myPromiseFn(param+1); // much nicer, right?
}

Hứa hẹn là tất cả về việc làm cho mã không đồng bộ dễ đọc hơn và hoạt động giống như mã đồng bộ mà không che giấu thực tế đó. Promise đại diện cho một sự trừu tượng hóa trên một giá trị của hoạt động một lần, chúng trừu tượng hóa khái niệm của một tuyên bố hoặc biểu thức trong ngôn ngữ lập trình.

Bạn chỉ nên sử dụng các đối tượng bị trì hoãn khi bạn đang chuyển đổi API thành các lời hứa và không thể tự động thực hiện hoặc khi bạn viết các hàm tổng hợp được thể hiện dễ dàng hơn theo cách này.

Trích dẫn Esailija:

Đây là mô hình chống phổ biến nhất. Thật dễ dàng rơi vào điều này khi bạn không thực sự hiểu lời hứa và nghĩ về chúng như các trình phát sự kiện được tôn vinh hoặc tiện ích gọi lại. Chúng ta hãy tóm tắt lại: các lời hứa là về việc tạo mã không đồng bộ giữ lại hầu hết các thuộc tính bị mất của mã đồng bộ như thụt lề phẳng và một kênh ngoại lệ.

Có gì sai với nó?

Nhưng mô hình hoạt động!

Bạn thật may mắn. Thật không may, nó có thể không, vì bạn có thể quên một số trường hợp cạnh. Trong hơn một nửa số lần tôi đã thấy, tác giả đã quên chăm sóc bộ xử lý lỗi:

return new Promise(function(resolve) {
    getOtherPromise().then(function(result) {
        resolve(result.property.example);
    });
})

Nếu lời hứa khác bị từ chối, điều này sẽ không được chú ý thay vì được truyền đến lời hứa mới (nơi nó sẽ được xử lý) - và lời hứa mới sẽ tồn tại mãi trong thời gian chờ xử lý, có thể gây rò rỉ.

Điều tương tự cũng xảy ra trong trường hợp mã gọi lại của bạn gây ra lỗi - ví dụ: khi resultkhông có propertyngoại lệ và một ngoại lệ được đưa ra. Điều đó sẽ được giải quyết và để lại lời hứa mới chưa được giải quyết.

Ngược lại, việc sử dụng .then()sẽ tự động xử lý cả hai tình huống này và từ chối lời hứa mới khi xảy ra lỗi:

 return getOtherPromise().then(function(result) {
     return result.property.example;
 })

Các antipotype bị trì hoãn không chỉ cồng kềnh, mà còn dễ bị lỗi . Sử dụng .then()để xích là an toàn hơn nhiều.

Nhưng tôi đã xử lý mọi thứ!

Có thật không? Tốt Tuy nhiên, điều này sẽ khá chi tiết và phong phú, đặc biệt nếu bạn sử dụng thư viện lời hứa hỗ trợ các tính năng khác như hủy bỏ hoặc chuyển tin nhắn. Hoặc có thể nó sẽ trong tương lai, hoặc bạn muốn trao đổi thư viện của bạn với một cái tốt hơn? Bạn sẽ không muốn viết lại mã của bạn cho điều đó.

Các phương thức của thư viện ( then) không chỉ hỗ trợ tất cả các tính năng, mà còn có thể có những tối ưu nhất định. Sử dụng chúng có thể sẽ làm cho mã của bạn nhanh hơn hoặc ít nhất là cho phép được tối ưu hóa bởi các phiên bản tương lai của thư viện.

Làm thế nào để tôi tránh nó?

Vì vậy, bất cứ khi nào bạn thấy mình tự tạo một Promisehoặc hoặc Deferrednhững lời hứa đã có sẵn, hãy kiểm tra API thư viện trước . Các antipotype bị trì hoãn thường được áp dụng bởi những người xem lời hứa [chỉ] như một mẫu quan sát - nhưng lời hứa còn hơn cả các cuộc gọi lại : chúng được cho là có thể ghép lại được. Mỗi thư viện phong nha đều có rất nhiều chức năng dễ sử dụng để sắp xếp các lời hứa theo mọi cách có thể nghĩ được, chăm sóc tất cả những thứ cấp thấp mà bạn không muốn đối phó.

Nếu bạn thấy cần phải soạn một số lời hứa theo cách mới không được hỗ trợ bởi chức năng trợ giúp hiện có, viết chức năng của riêng bạn với Trì hoãn không thể tránh khỏi sẽ là lựa chọn cuối cùng của bạn. Cân nhắc chuyển sang thư viện có nhiều tính năng hơn và / hoặc báo lỗi đối với thư viện hiện tại của bạn. Người bảo trì của nó sẽ có thể lấy được thành phần từ các chức năng hiện có, triển khai chức năng trợ giúp mới cho bạn và / hoặc giúp xác định các trường hợp cạnh cần xử lý.