async/await v JS

[ScriptKid]

Používáte to někdo? By mě zajímalo, proč okopírovali ten mizerný návrh korutin z C#.

[Reklama]

[Ziktofel]

Ano, pouzivam to casto

Hodne to vidim u kodu, kdy se tahaj dalsi HTTP requesty vicemene jako syntactic sugar k Promise (je to citelnejsi nez then)
Handlovani rejectnuti promisy se pak resi pres try/catch

[LadislavBohm]

Používáte to někdo? By mě zajímalo, proč okopírovali ten mizerný návrh korutin z C#.

Můžeš uvést příklad jazyka, kde je podle tebe lépe vyřešeno volání asynchronního kódu? Díky

[Neinformovaný]

Když jste u JS+async+await, tak bych se rád zeptal.
Taham data z DB, ale když se mi vrátí 0 řádků, měl bych jako neúspěch volat reject? Např. tady podle článku https://blog.tonysneed.com/2016/10/27/scalable-web-api-express-async-await/ jo, ale pak těžko rozeznam z chybový hlášky jestli je 0 výsledků nebo selhalo připojení k DB.

Podle mě by bylo lepší v případě 0 řádků volat resolve(null), jen v případě chyby DB reject(err) a vůbec nepoužívat try catch, protože v případě chyby připojení k DB chci shodit celou aplikaci. Stejně jako to dělam např. v PHP+Dibi.

[Bacsa]

Používáte to někdo? By mě zajímalo, proč okopírovali ten mizerný návrh korutin z C#.

Můžeš uvést příklad jazyka, kde je podle tebe lépe vyřešeno volání asynchronního kódu?

Kooperativní vícevláknovost je mnohem lépe vyřešena v Go, je plně transparentní a nemusí se zavádět async funkce. Vyžadovat psát async/await je zcela zbytečné, stejně jako používání Promise pro návratovou hodnotu. Jde o overengineering. Na druhou stranu to je o trochu lepší než callback hell.

[Reklama]

[mmm]

Když jste u JS+async+await, tak bych se rád zeptal.
Taham data z DB, ale když se mi vrátí 0 řádků, měl bych jako neúspěch volat reject? Např. tady podle článku https://blog.tonysneed.com/2016/10/27/scalable-web-api-express-async-await/ jo, ale pak těžko rozeznam z chybový hlášky jestli je 0 výsledků nebo selhalo připojení k DB.

Podle mě by bylo lepší v případě 0 řádků volat resolve(null), jen v případě chyby DB reject(err) a vůbec nepoužívat try catch, protože v případě chyby připojení k DB chci shodit celou aplikaci. Stejně jako to dělam např. v PHP+Dibi.

Ten článek je nesmysl. Borec používá Promisy zcela zbytečně v aplikaci bez asynchronního IO. Přečtěte si dokumentaci od Mozilly.

Když používáte async/await, resolve a reject nepotřebujete, pokud nepoužíváte nějaké historické knihovny nepodporující promisy.

[Bacsa]

Když jste u JS+async+await, tak bych se rád zeptal.
Taham data z DB, ale když se mi vrátí 0 řádků, měl bych jako neúspěch volat reject? Např. tady podle článku https://blog.tonysneed.com/2016/10/27/scalable-web-api-express-async-await/ jo, ale pak těžko rozeznam z chybový hlášky jestli je 0 výsledků nebo selhalo připojení k DB.

Podle mě by bylo lepší v případě 0 řádků volat resolve(null), jen v případě chyby DB reject(err) a vůbec nepoužívat try catch, protože v případě chyby připojení k DB chci shodit celou aplikaci. Stejně jako to dělam např. v PHP+Dibi.

Lepší je resolve s null nebo [].

[Filip Jirsák]

Když jste u JS+async+await, tak bych se rád zeptal.
Taham data z DB, ale když se mi vrátí 0 řádků, měl bych jako neúspěch volat reject? Např. tady podle článku https://blog.tonysneed.com/2016/10/27/scalable-web-api-express-async-await/ jo, ale pak těžko rozeznam z chybový hlášky jestli je 0 výsledků nebo selhalo připojení k DB.

Podle mě by bylo lepší v případě 0 řádků volat resolve(null), jen v případě chyby DB reject(err) a vůbec nepoužívat try catch, protože v případě chyby připojení k DB chci shodit celou aplikaci. Stejně jako to dělam např. v PHP+Dibi.

Když se ptáte na seznam, měl byste normálně vrátit prázdný seznam. Pokud se ptáte na jeden konkrétní záznam (dle primárního klíče), obecně byste měl vrátit null – ale pokud by ten záznam měl existovat (např. uživatel jde ze seznamu produktů, kde je produkt vypsaný, na detail produktu), dává smysl i vrátit chybu (reject nebo výjimku).

[mmm]

Kooperativní vícevláknovost je mnohem lépe vyřešena v Go, je plně transparentní a nemusí se zavádět async funkce. Vyžadovat psát async/await je zcela zbytečné, stejně jako používání Promise pro návratovou hodnotu. Jde o overengineering. Na druhou stranu to je o trochu lepší než callback hell.

asynchronnost bez explicitního await není kooperativní ani transparentní.

[Bacsa]

Kooperativní vícevláknovost je mnohem lépe vyřešena v Go, je plně transparentní a nemusí se zavádět async funkce. Vyžadovat psát async/await je zcela zbytečné, stejně jako používání Promise pro návratovou hodnotu. Jde o overengineering. Na druhou stranu to je o trochu lepší než callback hell.

asynchronnost bez explicitního await není kooperativní ani transparentní.

Je oboje, se podívej na scheduler v Go.

[mmm]

Je oboje, se podívej na scheduler v Go.

Nepodívám. Explicitní znamená, že je v programu explicitně řečeno, kdy dojde k přepnutí kontextu. Kooperativní to stejné.

[Bacsa]

Je oboje, se podívej na scheduler v Go.

Nepodívám. Explicitní znamená, že je v programu explicitně řečeno, kdy dojde k přepnutí kontextu. Kooperativní to stejné.

Škoda, zůstaneš v bludu 

[káva]

Icecofeescript >3

[LadislavBohm]

Používáte to někdo? By mě zajímalo, proč okopírovali ten mizerný návrh korutin z C#.

Můžeš uvést příklad jazyka, kde je podle tebe lépe vyřešeno volání asynchronního kódu?

Kooperativní vícevláknovost je mnohem lépe vyřešena v Go, je plně transparentní a nemusí se zavádět async funkce. Vyžadovat psát async/await je zcela zbytečné, stejně jako používání Promise pro návratovou hodnotu. Jde o overengineering. Na druhou stranu to je o trochu lepší než callback hell.

Neznám Go, ale když mluvíme o asynchronním zpracování, tak nechápu proč zmiňujete vícevláknovost. Promise ani async await v JS ani C# nesouvisí ani nijak nepředpokládají jakékoli zapojení více vláken do běhu programu. Při async await v C# například funkce může běžet zcela synchronně, vše závisí na její interní implementaci.
Osobně si myslím, že to je ten problém. Bavíme se tu o asynchronních funkcích v JS, kdy potřebujete vědět, zda funkce doběhla a vznikla přitom výjimka, nebo ne. Při async await syntaxi toho docílíte tak, že nemusíte větvit funkce a řešit přepínání this a kód syntakticky připomíná synchronní kód.
 
Async await navíc nepřejímá pouze JS, ale například i Python, Typescript a další.

[Bacsa]

Používáte to někdo? By mě zajímalo, proč okopírovali ten mizerný návrh korutin z C#.

Můžeš uvést příklad jazyka, kde je podle tebe lépe vyřešeno volání asynchronního kódu?

Kooperativní vícevláknovost je mnohem lépe vyřešena v Go, je plně transparentní a nemusí se zavádět async funkce. Vyžadovat psát async/await je zcela zbytečné, stejně jako používání Promise pro návratovou hodnotu. Jde o overengineering. Na druhou stranu to je o trochu lepší než callback hell.

Při async await syntaxi toho docílíte tak, že nemusíte větvit funkce a řešit přepínání this a kód syntakticky připomíná synchronní kód.

Ano, jistě. Já jen píšu, že je zbytečné anotovat kód pomocí async/await (a používat Promise), protože překladač může generovat zcela stejný kód i bez nich.