Разрешаване на синхронно обещание (bluebird срещу jQuery)

Кратка версия: Разбирам защо искате да направите това, но отговорът е не.

Мисля, че основният въпрос, който се задава, е дали завършено обещание трябва незабавно да изпълни обратно извикване, ако обещанието вече е изпълнено. Мога да се сетя за много причини това да се случи - например асинхронна процедура за запис, която записва данни само ако са направени промени. Може да е в състояние да открие промени от страна на клиента по синхронен начин, без да се налага да преминава през външен ресурс, но ако промените бъдат открити тогава и само тогава ще се изисква асинхронна операция.

В други среди, които имат асинхронни извиквания, моделът изглежда е, че разработчикът е отговорен за разбирането, че тяхната работа може да завърши незабавно (например внедряването на асинхронния шаблон на .NET framework се съобразява с това). Това не е проблем с дизайна на рамката, а начинът, по който е внедрена.

Разработчиците на JavaScript (и много от коментаторите по-горе) изглежда имат различна гледна точка по този въпрос, настоявайки, че ако нещо може да е асинхронно, то винаги трябва да бъде асинхронно. Дали това е „правилно“ или не е без значение – според спецификацията, която намерих на https://promisesaplus.com/, точка 2.2.4 заявява, че по принцип не могат да бъдат извикани обратни извиквания, докато не излезете от това, което ще наричам „код на скрипта“ или „потребителски код“; т.е. спецификацията казва ясно, че дори ако обещанието е изпълнено, не можете да извикате обратното извикване веднага. Проверих на няколко други места и те или не казват нищо по темата, или са съгласни с първоизточника. Не знам дали https://promisesaplus.com/ може да се счита за окончателен източник на информация в това отношение, но няма други източници, които Видях, че не съм съгласен с него и изглежда, че е най-пълният.

Това ограничение е донякъде произволно и аз честно казано предпочитам .NET перспективата за това. Ще оставя на другите да решат дали смятат за „лош код“ да направят нещо, което може или не може да бъде синхронно по начин, който изглежда асинхронен.

Вашият действителен въпрос е дали Bluebird може да бъде конфигуриран да изпълнява поведението, което не е JavaScript. По отношение на производителността може да има незначителна полза от това, а в JavaScript всичко е възможно, ако се постараете достатъчно, но тъй като обектът Promise става все по-разпространен в платформите, ще видите преминаване към използването му като роден компонент вместо персонализиран написан полифили или библиотеки. Като такъв, какъвто и да е отговорът днес, преработването на обещание в Bluebird вероятно ще ви създаде проблеми в бъдеще и вашият код вероятно не трябва да бъде написан така, че да зависи от или да предоставя незабавно разрешаване на обещание.

Може би си мислите, че това е проблем, защото няма начин да има

getSomeText('first').then(print);
print('second');

и да има getSomeText "first" отпечатано преди "second", когато резолюцията е синхронна.

Но мисля, че имате логически проблем.

Ако вашата getSomeText функция може да е синхронна или асинхронна, в зависимост от контекста, тогава тя не трябва да влияе на реда на изпълнение. Използвате обещания, за да сте сигурни, че винаги е едно и също. Наличието на променлив ред на изпълнение вероятно ще се превърне в грешка във вашето приложение.

Използвайте

getSomeText('first') // may be synchronous using cast or asynchronous with ajax
.then(print)
.then(function(){ print('second') });

И в двата случая (синхронен с cast или асинхронна резолюция) ще имате правилния ред на изпълнение.

Обърнете внимание, че наличието на функция, която понякога е синхронна, а понякога не, не е странен или малко вероятен случай (помислете за обработка на кеша или групиране). Просто трябва да предположите, че е асинхронно и всичко винаги ще бъде наред.

Но искането на потребителя на API да прецизира с булев аргумент, ако иска операцията да бъде асинхронна, изглежда няма смисъл, ако не напуснете областта на JavaScript (т.е. ако не използвате някакъв собствен код ).

Целта на обещанията е да направят асинхронния код по-лесен, т.е. по-близо до това, което усещате, когато използвате синхронен код.

Използвате синхронен код. Не го правете по-сложно.

function print( text ){

    console.log( 'print -> %s', text );

    return text;
}

function getSomeTextSimpleCast( opt_text ){

    var text = opt_text || 'Some fancy text-value';

    return text;
}

print(getSomeTextSimpleCast('first'));
print('second');

И това трябва да е краят.

Ако искате да запазите същия асинхронен интерфейс, въпреки че вашият код е синхронен, тогава трябва да го направите докрай.

getSomeTextSimpleCast('first')
    .then(print)
    .then(function() { print('second'); });

then изважда вашия код от нормалния поток на изпълнение, защото се предполага, че е асинхронен. Bluebird го прави по правилния начин. Просто обяснение какво прави:

function then(fn) {
    setTimeout(fn, 0);
}

Имайте предвид, че bluebird всъщност не прави това, само за да ви даде прост пример.

Опитай!

then(function() {
    console.log('first');
});
console.log('second');

Това ще изведе следното:

second
first 

Тук вече има някои добри отговори, но за да обобщим същината на въпроса много накратко:

Наличието на обещание (или друг асинхронен API), който понякога е асинхронен, а понякога синхронен, е лошо нещо.

Може да мислите, че е добре, защото първоначалното извикване на вашия API приема булево значение за превключване между синхронизиране/асинхронизиране. Но какво ще стане, ако това е заровено в някакъв обвиващ код и лицето, използващо този код, не знае за тези шенанигани? Току-що са завършили с някакво непредсказуемо поведение без вина по тяхна вина.

Изводът: Не се опитвайте да правите това. Ако искате синхронно поведение, не връщайте обещание.

С това ще ви оставя този цитат от Не познавате JS:

Друг проблем с доверието се нарича „твърде рано“. От гледна точка на конкретното приложение, това всъщност може да включва извикване, преди да бъде завършена някаква критична задача. Но по-общо, проблемът е очевиден в помощните програми, които могат или да извикат обратното извикване, което предоставяте сега (синхронно), или по-късно (асинхронно).

Този недетерминизъм около поведението на синхронизиране или асинхронизиране почти винаги ще доведе до много трудни за проследяване грешки. В някои кръгове измисленото предизвикващо лудост чудовище на име Залго се използва за описание на синхронизираните/асинхронни кошмари. — Не пускай Залго! е често срещан вик и води до много разумен съвет: винаги извиквайте обратните извиквания асинхронно, дори ако това е „веднага“ на следващия ход на цикъла на събитието, така че всички обратни извиквания да са предвидимо асинхронни.

Забележка: За повече информация относно Zalgo вижте "Don't Release Zalgo!" на Oren Golan. (https://github.com/oren/oren.github.io/blob/master/posts/zalgo.md) и „Designing APIs for Asynchrony“ на Isaac Z. Schlueter (http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony).

Обмисли:

function result(data) {
    console.log( a );
}

var a = 0;

ajax( "..pre-cached-url..", result );
a++;`

Ще отпечата ли този код 0 (извикване на обратно извикване при синхронизиране) или 1 (извикване на обратно извикване на асинхронно)? Зависи... от условията.

Можете да видите колко бързо непредсказуемостта на Zalgo може да застраши всяка JS програма. Така че глупаво звучащото „никога не пускайте Zalgo“ всъщност е невероятно често срещан и солиден съвет. Винаги бъдете асинхронни.

Какво ще кажете за този случай, също свързан с CrmFetchKit, който в последната версия използва Bluebird. Надстроих от версия 1.9, която беше базирана на jQuery. Все още старият код на приложението, който използва CrmFetchKit, има методи, чиито прототипи не мога или не искам да променя.

Съществуващ код на приложението

CrmFetchKit.FetchWithPaginationSortingFiltering(query.join('')).then(
    function (results, totalRecordCount) {
        queryResult = results;

        opportunities.TotalRecords = totalRecordCount;

        done();
    },
    function err(e) {
        done.fail(e);
    }
);

Стара реализация на CrmFetchKit (персонализирана версия на fetch())

function fetchWithPaginationSortingFiltering(fetchxml) {

    var performanceIndicator_StartTime = new Date();

    var dfd = $.Deferred();

    fetchMore(fetchxml, true)
        .then(function (result) {
            LogTimeIfNeeded(performanceIndicator_StartTime, fetchxml);
            dfd.resolve(result.entities, result.totalRecordCount);
        })
        .fail(dfd.reject);

    return dfd.promise();
}

Нова реализация на CrmFetchKit

function fetch(fetchxml) {
    return fetchMore(fetchxml).then(function (result) {
        return result.entities;
    });
}

Проблемът ми е, че старата версия имаше dfd.resolve(...), където успях да предам произволен брой параметри, които ми трябват.

Новата реализация просто се връща, родителят изглежда извиква обратното извикване, не мога да го извикам директно.

Отидох и направих персонализирана версия на fetch() в новата реализация

function fetchWithPaginationSortingFiltering(fetchxml) {
    var thePromise = fetchMore(fetchxml).then(function (result) {
        thePromise._fulfillmentHandler0(result.entities, result.totalRecordCount);
        return thePromise.cancel();
        //thePromise.throw();
    });

    return thePromise;
}

Но проблемът е, че обратното извикване се извиква два пъти, веднъж, когато го правя изрично и втори път от рамката, но тя му предава само един параметър. За да го измамя и да "кажа" да не извиквам нищо, защото го правя изрично, се опитвам да извикам .cancel(), но той се игнорира. Разбрах защо, но все пак как се прави "dfd.resolve(result.entities, result.totalRecordCount);" в новата версия, без да се налага да променяте прототипи в приложението, което използва тази библиотека?

Всъщност можете да направите това, да.

Променете файла bluebird.js (за npm: node_modules/bluebird/js/release/bluebird.js) със следната промяна:

[...]

    target._attachExtraTrace(value);
    handler = didReject;
}

- async.invoke(settler, target, {
+ settler.call(target, {
    handler: domain === null ? handler
        : (typeof handler === "function" &&

[...]

За повече информация вижте тук: https://github.com/stacktracejs/stacktrace.js/issues/188