-1

I'm writing code in Typescript and I'm having trouble with libraries which lack synchronic functions/methods. I just need to wait for a promise to be resolved and I can't find a reasonable way of doing so. What I intend to do is just:

public someObjectMethod(): any {
    externalLibrary.doSomeghing()
    // wait for that something to happen
    // continue doing stuff

I know I can make the method async so it returns a Promise and then declare the calling method async too so that it also returns a Promise and so on until I eventually get to a point where I can await, but if I do that I'll end up with an object model where every method is async and every object is a Promise. The thing is that I took Typescript for this expecting to be able to write OO code and not a Javascript script. I don't think using Promises, async and await will scale in a big OO model and I really don't need the extra performance I can get from asynchronous calls but rather the flow control I can get from synchronous calls.

So the question is... Is there a - reasonable - way to wait for Promises to resolve?

THIS IS NOT A DUPLICATE QUESTION!

I'm asking if there's a reasonable way of waiting for a Promise to resolve in the context of writing an object-oriented model. Changing all functions in the call trace to async and then handling Promises everywhere is not a reasonable way of solving this problem. I need to know if there's a way of just waiting for a Promise to resolve instead of changing the signature of half my code every time I come across a library which doesn't have synchronous implementations.

Brad
  • 159,648
  • 54
  • 349
  • 530
Guillermo Ares
  • 197
  • 1
  • 12
  • 3
    Why do you think promises are not scalable? Why do you feel the need to use `await` everywhere? Why do you think a promise-based API is not reasonable? – Brad Aug 16 '18 at 22:33
  • `every time I come across a library which doesn't have synchronous implementations` - usually, if a library is asynchronous (either using callbacks, promises, or some other methods) it's because it needs to be. You can't (easily) turn asynchronous to synchronous - so this statement is meaningless really. If you want to program in a language with no asynchrony, javascript is a bad choice – Jaromanda X Aug 16 '18 at 23:07
  • I'd really be interested to know what sort of code you're creating that does everything synchronously – Jaromanda X Aug 16 '18 at 23:12

1 Answers1

1

Once you're invoking async code - whether it uses "callback hell", Promises, async/await (syntactic sugar around Promises), or even something Monadic (is that a dirty word?) - I'm afraid you're stuck in async code.

You can convert between callback syntax and Promises, if you like.

function foo(cb: (err: any, value: string) => void): void {
   doSomethingPromisey()
       .then(
           (value) => cb(null, value),
           cb
       );
}

foo((err: any, value: string) => {
    if (err) {
        // Do something with the error here.
        // Note that throwing an error will just cause a Promise rejection - once you're in a Promise chain, there's no escaping!
        throw new Error("It didn't work :(");
    } else {
        console.log(value);
    }
});

But this isn't want you want.

I see your options as:

  • Fork the libraries to write synchronous versions of the code.
  • Accept Promises into your life & codebase.

Based on my experience, you have nothing to fear using promises in OO code. :)

Laurence Dougal Myers
  • 1,004
  • 1
  • 8
  • 17
  • 1
    I don't have a problem with asynchronous calls, they can be useful here and there. The thing is that this model is evolving and as soon as I have to use some strictly asynchronous library deep down in my code, I end up having to "asynchronize" stuff up the call stack, even if it makes no practical sense. I end up adding unnecessary multithreading complexity to my code, which I'd like to be able to avoid completely in most cases. But well, you answered my question: There's no solution to this aside adding multithreading complexity to my code or forking external libraries. Thank you! – Guillermo Ares Aug 17 '18 at 13:16
  • Hey @GuillermoAres, I’m having the very same problem with asynchronizing all the way up the call stack that you do/did. May I ask your take on this now, 3 years later? Did you find another solution or just learned to live with it? – balanceglove2 Nov 04 '21 at 22:51
  • @LeonTepe Ahm... not really. You'll have to play with it. Sometimes using `then` instead of async/await helps readability. You could also try googling "npm async to sync". There are some packages but I'm not sure if they are any good. – Guillermo Ares Nov 08 '21 at 11:50