Promisy bluebirdowe i async/await

General
1

Przy okazji pracy nad strategią NOT odkryłem buga - mamy tam taki fragment kodu:

strategy
	.getRestrictingQuery(context)
	.then(query => query.toPipeline())
	.filter(

W chwili obecnej getRestrictingQuery jest funkcją asynchroniczną czyli zwraca Promise ale natywny, a nie bluebirdowy. Nie można tego zhijackować, to co moglibyśmy zrobić to gdzieś głębiej opakowywać tę funkcję w Promise bluebirdowy. Wydaje mi się, że coś z tym trzeba zrobić, bo dwa rodzaje promisów z różnym API mogą nas ugryźć ponownie.

2

Hmm a gdzie polegaliśmy na tym, że zwracany był promise bluebirdowy?

W moim odczuciu powinniśmy zawsze zakładać, że zwracamy promisy natywne. Bluebird był bardzo pomocny jak nie było async/await i najbardziej eleganckim rozwiązaniem było chainowanie. Ale teraz jak mamy async/await i możemy korzystać z pętli itp to właściwie przydaje się w Bluebirdzie niewiele więcej niż Promise.all (bo np. .map możemy wywołać bezpośrednio na awaitowanej tablicy)

1 Like
3

No właśnie w strategii NOT w tym fragmencie - zakładaliśmy, że mamy w promisie funkcję filter - typowo bluebirdowy feature.

Poza tym to co napisałeś mogę tylko tak skomentować:

Great minds think alike

4

och ślepy ja xd

Cieszę się, że mamy podobny punkt widzenia :smiley:

Trzeba byłoby zrobić audyt Sealiousa pod tym względem - myślisz, że to zasługuje na osobnego taska?

1 Like
5

Żeby łatwiej taki audyt przeprowadzić, można ustawić taska z nim jako zależnego od T863 (penetracja całego Sealiousa Prettierem) :slight_smile:

2 Likes
6

Ok, założyłem taska

https://hub.sealcode.org/T869