i'm using typescript , async/await represent asynchronous workflow. part of workflow call out web worker , continue when calls result.
in c#, i'd create taskcompletionsource, await task , elsewhere in code call setresult resolve taskcompletionsource.
i can same thing in javascript initializing deferrer object using promise.defer(), awaiting promise , elsewhere, in window.onmessage listener call resolve (or reject) method let asynchronous workflow continue.
sounds lovely, mdn says defer obsolete. proposed solution of using promise constructor takes delegate doing work , calling resolve/reject methods doesn't work me, because logic out of reach, want on object call resolve or reject on in entirely different lexical scope, can't function.
there's backwards , forwards compatible helper gives me such object binding resolve , reject functions can use without chaning semantics of code. bad practice? there recognized, better pattern? what's idiomatic equivalent of taskcompletionsource in javascript?
there absolutely nothing wrong helper makes deferred long sure need deferred. in promise programming, i've found 1 situation needed deferred , couldn't restructure code use typical promise constructor pattern.
it seems situation found , 1 others have pointed occurs when have separate between code creates promise/deferred object , code resolves or rejects it. usually, have together, there when different sections of code , there logical reasons doing way. in cases, deferred object built off regular promise can cleaner method of implementation.
here's simple deferred implementation backwards , forwards compatible:
why promise constructor need executor?
but bad practice?
i know there purists out there think should never this. but, i'd it's fine practice if sure cleanest , simplest way implement code , implementing typical promise constructor executor callback isn't practical. there want use deferred without trying or learning promise constructor/executor , not practice. variety of reasons, promise constructor should used when practical.
one big reason promise constructor preferred promise-specific code in executor callback function "throw-safe". if exception thrown in code, automatically caught , reject promise (which thing). once use deferred , have bunch of code manipulates promise outside of callback, not automatically throw-safe. in fact, code can throw synchronously nightmare callers protect against. can see description of issue here: https://stackoverflow.com/a/37657831/816620. so, deferred pattern not preferred, proper protections, there still cases (generally rare) leads cleaner implementation.
is there recognized, better pattern?
pretty same answer above. preference use promise constructor/executor, in situations isn't practical (usually different sections of code create promise , resolve/reject it) , there's no simple way reorganize code work promise constructor/executor, deferred object preferred implementation. should find situations rare because of time can structure code same chunk of code creating , resolve/rejecting promise , don't need deferred.
what's idiomatic equivalent of taskcompletionsource in javascript?
there no built-in equivalent in javascript. such, you'd have build own , seems promises natural way since naturally built signal completion or error. you'd have show actual code offer opinion on whether specific situation can implemented cleanly without using deferred object.
Comments
Post a Comment