Asynchroniczna pętla, Rozważania nad API Opcje

[Comandeer]

Pytanie natury czysto teoretycznej. Załóżmy, że tworzę sobie API dla pewnego projektu X i musi być ono de facto w pełni asynchroniczne. Oczywistym wyborem są tutaj obiecanki - wszak nikt nie lubi się babrać w callbackach.

Wszystko jest cacy, ALE (IMG:style_emoticons/default/wink.gif) Potrzebna jest mi asynchroniczna wersja pętli [].forEach - metoda X.each (żeby się nikt nie rąbnął z natywnym [].forEach; chyba żeby iść w coś typu X.forEachAsync?). Na każdym elemencie mogą być wykonywane operacje asynchroniczne i pętla powinna "czekać".

Na chłopski rozum implementacja powinna się opierać na Promise.all i każdy przepuszczany przez X.each element powinien być obiecanką. Tak na szybko "backend" czegoś takiego mógłby wyglądać np. tak (oczywiście pewnie będzie wyglądać ciut bardziej złożenie (IMG:style_emoticons/default/wink.gif) ):

Kod

var promises = [];

pool.forEach(function(item)
{
    var promise = toPromise(item);
    callback(promise);
    promises.push(promise);
});

return Promises.all(promises);

Zatem wywołanie X.each wyglądałoby następująco:

Kod

X.each(function(promise)
{
    
})
.then(function(returnValues)
{
    //po pętelce
});

User dostawałby po prostu dostęp do obiecanki - proste i przyjemne. Pojawia się jednak pewien problem: zaburza to koncepcję chainingu - przy takim wywołaniu nie dostaniemy pojedynczej wartości (a zatem mitycznego this) tylko tablicę dowolnych wartości (user może zwrócić wszystko w obiecance). W zależności od naszego widzimisię może to być dobrze lub źle (ale raczej źle). Stąd myślę czy nie ograniczyć możliwości usera wprowadzając pewien rodzaj nakładki, analogiczny do tego, jaką udostępniają np. taski asynchroniczne w Gruncie - user miałby dostęp tylko do funkcji done (z tym, że wówczas bebechy operowałyby raczej na pojedynczynm Promise a nie ich tablicy):

Kod

X.each(function(done)
{
    done(); //wszystko cacy
    done(jakakolwiekWartosc); //coś się zepsuło
})
.then(function(X)
{
    //itd
});

Tym sposobem w X.each().then na pewno uzyskamy z powrotem X, co np. w dalszej kolejności uprzyjemni obcowanie z biblioteką przy wykorzystywaniu generatorów.

Pytania brzmią:

• Czy oparcie bebechów tego czegoś na Promise.all/Promise brzmi sensownie?
  
• Czy lepiej udostępnić userowi dostęp do obiecanki wewnątrz X.each i nie mieć kontroli nad tym, co zwróci całość, czy dać mu jedynie dostęp do done i w pełni kontrolować to, co zostanie zwrócone?
  
• X.each czy X.forEachAsync? (IMG:style_emoticons/default/wink.gif) Chociaż pewnie każdy, kto pracował kiedyś z jQuery i tak wybierze 1. wersję

[Comandeer]

Dlatego wgl o tym done pomyślałem, żeby móc uruchamiać całość wewnątrz generatora, co by uprościło składnię do de facto minimum. Wówczas mielibyśmy prawie synchroniczny kod.

Owszem, done nie pojawi mi się od tak. Widzę to jako prostą funkcję, która resolvuje promise jeśli nic jej nie przekazaliśmy i rejectuje jeśli dostanie parametr. I funkcja ta byłaby przekazywana do pętli zamiast całej obiecanki. Co do wprowadzania w błąd - done nie jest częścią standardu obiecanek, więc nie bardzo wiem gdzie tu wprowadzanie w błąd? https://promisesaplus.com tą metodę wprowadza raptem kilka bibliotek + niekompatybilna ze standardem składnia jQuery. W natywnej implementacji obiecanek w ES6 metoda ta nie występuje, bo jedyne co robi to dubluje then