Я писав код, який робить щось таке:

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() */ |     });
}                                        | }

Хтось сказав мені, що це називається " відкладений антипатерн " або " Promiseконструктор антипатерн " відповідно, що поганого в цьому коді і чому його називають антипатерн ?

Відклали антипаттерн (тепер явно-будівельна антипаттерн) придуманий Esailija є загальними антипаттерн людей , які є новими для обіцянки зробити, я зробив це саме , коли я вперше використав слово. Проблема з наведеним вище кодом полягає в тому, що він не використовує той факт, що обіцяє ланцюжок.

Обіцяння можуть зв'язатись, .thenі ви можете повернути обіцянки безпосередньо. Ваш код у getStuffDoneможна переписати як:

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

Обіцянки полягають у тому, щоб зробити асинхронний код більш читабельним і поводитись як синхронний код, не приховуючи цього факту. Обіцяння являють собою абстракцію над значенням одноразової операції, вони абстрагують поняття висловлювання чи виразу мовою програмування.

Ви повинні використовувати відкладені об'єкти лише тоді, коли ви перетворюєте API в обіцянки і не можете це зробити автоматично або коли ви пишете функції агрегації, які легше виражаються таким чином.

Цитуючи Esailija:

Це найпоширеніший антидіапазон. Легко впасти в це, коли ти не дуже розумієш обіцянки і не вважаєш їх прославленими випромінювачами подій або утилітою зворотного виклику. Давайте резюмуємо: обіцянки про те, щоб асинхронний код зберігав більшість втрачених властивостей синхронного коду, таких як плоский відступ та один канал виключення.

Що не так з ним?

Але візерунок працює!

Щасливчик. На жаль, це, мабуть, не так, як ви, ймовірно, забули якийсь крайній випадок. Більше половини випадків, які я бачив, автор забув подбати про обробку помилок:

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

Якщо інша обіцянка буде відхилена, це станеться непоміченим, замість того, щоб поширюватись на нову обіцянку (там, де вона впорається) - і нова обіцянка залишається назавжди очікуваною, що може викликати витоки.

Те ж саме відбувається в тому випадку, коли ваш код зворотного дзвінка викликає помилку - наприклад, коли resultнемає propertyта викинуто виняток. Це не піде на розгляд, а нова обіцянка залишиться невирішеною.

На противагу цьому, використання .then()автоматично бере на себе обидва ці сценарії та відхиляє нову обіцянку, коли трапляється помилка:

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

Відкладений антипатерн не тільки громіздкий, але й схильний до помилок . Використовувати .then()для прикування набагато безпечніше.

Але я впорався з усім!

Дійсно? Добре. Однак це буде досить детально та багато, особливо якщо ви використовуєте бібліотеку обіцянок, яка підтримує інші функції, такі як скасування чи передача повідомлення. А може, це буде в майбутньому, або ви хочете поміняти свою бібліотеку на кращу? Ви не хочете, щоб переписати свій код для цього.

Методи бібліотек (then ) не лише підтримують усі функції, але й можуть мати певні оптимізації. Використання їх, швидше за все, зробить ваш код швидшим або, принаймні, дозволить оптимізуватися майбутніми версіями бібліотеки.

Як я цього уникаю?

Тому щоразу, коли ви виявите, що вручну створюються Promiseабо Deferredвже залучені обіцянки, спочатку перевірте API бібліотеки . Відкладений антипатерн часто застосовується людьми, які бачать обіцянки [лише] як зразок спостерігача - але обіцянки більше, ніж зворотні дзвінки : вони повинні бути композиційними. Кожна порядна бібліотека має безліч простих у використанні функцій для складання обіцянок у будь-який тонкий спосіб, піклуючись про всі матеріали низького рівня, з якими ви не хочете мати справу.

Якщо ви виявили необхідність складати деякі обіцянки по-новому, що не підтримується існуючою допоміжною функцією, написання власної функції з неминучими відкладеннями має бути вашим останнім варіантом. Подумайте про перехід на більш функціональну бібліотеку та / або подайте помилку в поточну бібліотеку. Її обслуговуючий персонал повинен мати можливість отримувати композицію з існуючих функцій, реалізовувати нову функцію помічника для вас та / або допомагати виявляти крайні випадки, з якими потрібно працювати.