JS Promise

[L..]

Když odstraníte to zbytečné Promise, dostanete kód, o kterém jsem psal já a L..

Jojo, proč to napsat jednoduše na jeden řádek, když se to dá napsat složitě na devět...

[Reklama]

[Google CTCCTCGGCGGGCACGTAG]

Kurna, to se mi ani cist poradne nechtelo, takvy zmateny dotaz. Dam ti tip, ujasni si:

1. Co je to promis
2. Co je to asynchronni volani funkce
3. K cemu je async a await keywords
4. Proc node.js standardni knihovni funkce nevraci promis - protoze jsou stare.
5. Jak si muzes libovolnou starou asynchronni funkci v node.js sam predelat na promis
6. A jak si nad tim pak muzes pouzit async await.

A mas to. A jestl ito chces mit komplet, tak jeste

7. Co je to event loop v node.js a web browseru

tazatel ma jasno, ale Jirsak a L. neodpovidaji na jeho otazku.

[Google CTCCTCGGCGGGCACGTAG]

Když odstraníte to zbytečné Promise, dostanete kód, o kterém jsem psal já a L..

Jojo, proč to napsat jednoduše na jeden řádek, když se to dá napsat složitě na devět...

je to na jeden radek, kdyz pouzije hotovou synchronizacni primitivu (funkce Closer v me odpovedi), nebo alternativni Promise, treba Bluebird, ktery tohle umi out of box.

[L..]

je to na jeden radek, kdyz pouzije hotovou synchronizacni primitivu (funkce Closer v me odpovedi), nebo alternativni Promise, treba Bluebird, ktery tohle umi out of box.

Jenže moje (naše) řešení problému nepotřebuje žádný extra kód navíc. Prostě jednoduché vrácení funkce, kterou následně zavolá. Čistší, jednodušší, průhlednější, kratší.

[Filip Jirsák]

tazatel ma jasno, ale Jirsak a L. neodpovidaji na jeho otazku.

Ne, tazatel nemá jasno. Já a L.. jsme popsali správné řešení jeho problému (když jsme se konečně dozvěděli, jaký problém řeší). Zato vaše odpovědi jsou zmatené – tazatel se ptá, jak má použít Promise, a vy mu odpovíte, že má použít Defer/Deferred, což je jenom jiný název pro Promise. A použití Promise je v tazatelově případu nesmysl, protože Promise se používá v případech, kdy mám nějaký proces, který běží z pohledu mého kódu asynchronně na pozadí a já potřebuji být informován o jeho dokončení. Tady je to ale opačný případ, tazatel nechci být informován o dokončení, ale naopak chce asynchronní proces ukončit – směr té komunikace je opačný. Promise se tam dá vnutit, jak jsem psal hned v první odpovědi, ale je to matoucí. A matoucí kód je špatně, protože často nepoznáte, jestli v něm je nebo není chyba – a pokud to poznáte teď, nepoznáte to vy nebo někdo jiný později, až ten kód budete upravovat.

[Reklama]

[Ondrej Nemecek]

tazatel ma jasno, ale Jirsak a L. neodpovidaji na jeho otazku.

Ne, tazatel nemá jasno. Já a L.. jsme popsali správné řešení jeho problému (když jsme se konečně dozvěděli, jaký problém řeší). Zato vaše odpovědi jsou zmatené – tazatel se ptá, jak má použít Promise, a vy mu odpovíte, že má použít Defer/Deferred, což je jenom jiný název pro Promise. A použití Promise je v tazatelově případu nesmysl, protože Promise se používá v případech, kdy mám nějaký proces, který běží z pohledu mého kódu asynchronně na pozadí a já potřebuji být informován o jeho dokončení. Tady je to ale opačný případ, tazatel nechci být informován o dokončení, ale naopak chce asynchronní proces ukončit – směr té komunikace je opačný. Promise se tam dá vnutit, jak jsem psal hned v první odpovědi, ale je to matoucí. A matoucí kód je špatně, protože často nepoznáte, jestli v něm je nebo není chyba – a pokud to poznáte teď, nepoznáte to vy nebo někdo jiný později, až ten kód budete upravovat.

Zrovna tak můžeme čtecí proces považovat za poskytovatele dat který chce být informován pokud o jeho data není nadále zájem (= zanikne poslední  odběratel dat). Pak o tom chce být informován protože může přestat stream zpracovávat. Tedy je to celé o tom, jak je ten pohled v kontextu dané aplikace postavený - to by měla konceptuálně nastavit právě ta aplikace, aby programátor věděl, jak má na co nahlížet. Jinak ale samozřejmě souhlasím s tím, že Promise je typicky slib budoucích dat nikoli signalizace ukončení jejich odběru. Mimochodem EventBus mi přijde jako vhodný způsob pro obecné informování o změnách stavu různých komponent v aplikaci - ideální pro prototypování, kdy ještě nevíme, jak budou komponenty přesně komunikovat (umožňuje to později rozpoznat specializace a konkretizovat komunikaci podle určení, směru komunikace, trvalosti dat apod.).

[Google CTCCTCGGCGGGCACGTAG]

tazatel se ptá, jak má použít Promise, a vy mu odpovíte, že má použít Defer/Deferred, což je jenom jiný název pro Promise.

neni to stejne https://stackoverflow.com/a/17308358

deferred umoznuje resolvovat a rejectovat manualne z vnejsku, ES6 promisy nemaji deferred interface.

A použití Promise je v tazatelově případu nesmysl, protože Promise se používá v případech, ...

Promise je low level koncept, ktery jde prirozene pouzit v jakemkoliv kodu, ktery na neco ceka (v tazatelove pripade na ukonceni)

[Filip Jirsák]

neni to stejne https://stackoverflow.com/a/17308358

deferred umoznuje resolvovat a rejectovat manualne z vnejsku, ES6 promisy nemaji deferred interface.

Je to stejná implementace. Promise i defer/deferred je obecné označení pro objekt, který umožňuje volat kód „později“, při splnění nějaké podmínky. Případně se to někdy používá pro označení konkrétní části rozhraní – promise je ta část rozhraní, která umožňuje reagovat, defer/deferred je ta část rozhraní, která může aktivovat reakci. Ale implementace je stejná, protože aby to k něčemu bylo, potřebujete vždy obě dvě části – jak spouštěč, tak posluchač.

Váš kód umožňuje resolvovat Promise manuálně z vnějššku, takže to Promise evidentně umožňuje.

Promise je low level koncept, ktery jde prirozene pouzit v jakemkoliv kodu, ktery na neco ceka (v tazatelove pripade na ukonceni)

Ne, v tazatelově případu se nečeká na ukončení. Tazatel chce naopak ukončení ručně vyvolat. Ten směr je opačný – a asi to mate nejen tazetele, ale i vás.

[gleng]

Jenže moje (naše) řešení problému nepotřebuje žádný extra kód navíc. Prostě jednoduché vrácení funkce, kterou následně zavolá. Čistší, jednodušší, průhlednější, kratší.

Tvoje "Čistší, jednodušší, průhlednější, kratší." riesenie exportuje internu implementaciu funkcie ktoru caller nema vobec so riesit.  Inak povedane, caller len doda funciu na spracovanie dat a "funkciu" na oznamenie ked uz o data nema zuajem. Nic viac. On nema co riesit odkial alebo ako sa data stahuju.

[gleng]

Este ma napadol kompromis medzi tym co som chcel ja a co sa tu proklamuje ako najlepsie riesenie:

Kód: [Vybrat]

let closer = function() {}

function close() {
  closer()
  closer = function() {}
}

function setCloser(c) {
  closer = c
}

function streamData(req, setCloser, ok, nok) {
...
setCloser(events.close)
}

...ked nastane cas tak len

Kód: [Vybrat]

close()

[Ink]

Tvoje "Čistší, jednodušší, průhlednější, kratší." riesenie exportuje internu implementaciu funkcie ktoru caller nema vobec so riesit.

Tohle mě zajímá; co je u Tebe export interní implementace, snad ne tohle:

Kód: [Vybrat]

  return () => events.close();


[gleng]

ta funkcia streamData je iba jedna z mnohych funkcii a patri do api kniznice kde sa pracuje s promismi(axios) takze musi mat totoznu logiku ako vsetky ostatne funkcie, ktore nemaju navratovu hodnotu. preto som nemohol/nechcel nic vratit.

ano, hovorit o exportovani internej implementacie je prehnane kedze sme v javascripte, je to zvyk.

return () => events.close by stacilo, ale ako som pisal hore, staci ju zabalit do toho setCloser-u ako anonymnu funkciu.

[Google CTCCTCGGCGGGCACGTAG]

Este ma napadol kompromis medzi tym co som chcel ja a co sa tu proklamuje ako najlepsie riesenie:

Kód: [Vybrat]

let closer = function() {}

function close() {
  closer()
  closer = function() {}
}

function setCloser(c) {
  closer = c
}

function streamData(req, setCloser, ok, nok) {
...
setCloser(events.close)
}

...ked nastane cas tak len

Kód: [Vybrat]

close()

kdyz uz pouzivate globalni promenne, proc neudelate globalni ten eventsource?

[Google CTCCTCGGCGGGCACGTAG]

Váš kód umožňuje resolvovat Promise manuálně z vnějššku, takže to Promise evidentně umožňuje.

protoze jsem pridal metodu resolve a tim jsem z promisu udelal (castecny) deferred.

[Filip Jirsák]

Tvoje "Čistší, jednodušší, průhlednější, kratší." riesenie exportuje internu implementaciu funkcie ktoru caller nema vobec so riesit.

Vy stále nevíte, co ten váš kód vlastně dělá a co má dělat. Caller neexportuje žádnou interní implementaci. Caller exportuje API, ve kterém je funkce, kterou se oznamuje, že už o data nemáte zájem.

Inak povedane, caller len doda funciu na spracovanie dat a "funkciu" na oznamenie ked uz o data nema zuajem.

Tak si tohle rozeberte pořádně. Kdo komu oznamuje (posílá zprávu), že o data nemá zájem? Konzument zpráv a nebo stream? A volání funkce znamená poslání zprávy nebo přijetí zprávy?

ta funkcia streamData je iba jedna z mnohych funkcii a patri do api kniznice kde sa pracuje s promismi(axios) takze musi mat totoznu logiku ako vsetky ostatne funkcie, ktore nemaju navratovu hodnotu. preto som nemohol/nechcel nic vratit.

Tohle jste ale v popisu problému nenapsal. Navíc ta vaše funkce nemá totožnou logiku jako něco jiného, vaše funkce nemá žádnou logiku. To, zda funkce má nebo nemá návratovou hodnotu, není věcí logiky, ale pouze návrhu API.

ano, hovorit o exportovani internej implementacie je prehnane kedze sme v javascripte, je to zvyk.

Ale JavaScript samozřejmě umí omezení platnosti proměnných, nové verze dokonce umí i privátní proměnné a metody.

Na začátku jste psal, že JavaScript není vaše doména. Použít v takovém případě nesmyslné řešení, kterému navíc nerozumíte, když máte k dispozici správné řešení, je dost hloupé. Ale je to váš (marný) boj, když trváte na tom, že to musíte mít špatně, mějte si to špatně. Já jenom doufám, že ten kód nikdy nepotkám, ani jako uživatel.