JavaScript Detect Async Function

By  on  

JavaScript async/await has changed the landscape of how we code. We're no longer stuck in callback or then hell, and our code can feel more "top down" again.

Async functions require the following syntax:

async function myFunction() {

}

To use await with a function, the function needs to be declared with async. That got me to thinking: is it possible to detect if a function is asynchronous?

To detect if a function is asynchronous, use the function's constructor.name property:

const isAsync = myFunction.constructor.name === "AsyncFunction";

If the value is AsyncFunction, you know the function is async!

Async functions are my preferred method of working with promises. Knowing if a function is async could be useful as a library creator or a typing/validation utility.

Recent Features

Incredible Demos

  • By
    Image Manipulation with PHP and the GD Library

    Yeah, I'm a Photoshop wizard. I rock the selection tool. I crop like a farmer. I dominate the bucket tool. Hell, I even went as far as wielding the wizard wand selection tool once. ...OK I'm rubbish when it comes to Photoshop.

  • By
    CSS Triangles

    I was recently redesigning my website and wanted to create tooltips.  Making that was easy but I also wanted my tooltips to feature the a triangular pointer.  I'm a disaster when it comes to images and the prospect of needing to make an image for...

Discussion

  1. Sam

    This seems like a bad idea to me. You shouldn’t ever need to know if a function is asynchronous, because it can be treated the same as a non-async function that returns a Promise, and all functions can be treated as if they return a Promise by enclosing the call in Promise.resolve(). I can’t think of a single circumstance when this would actually be a sensible way to achieve a goal.

    • Craig

      There are semantic conditions under which a user supplied callback MUST NOT be async. Even within an async function JS is atomic within synchronous code slice boundaries. Every ‘await’ call adds a boundary. Having a boundary, or not, at the callback execution can be the semantic difference between requiring extra buffering or not.

      That shouldn’t be confused with whether it is grammatically possible to ‘equalize’ all callbacks by wrapping them in a Promise so that they are all asynchronous.

  2. I would just like to point out, you should avoid trying to detect if a function is async or not. The reason is, there’s really no difference between these two functions, in terms of how they should be used:

    async function getPerson(id) { .. }
    
    function getRecord(id) {
       return getPerson(id)
          .then(function(person){ return { data: person }; });
    }
    

    In other words, both functions return a promise, and thus you should interact with both of them in the same way, receiving that promise and doing something appropriate with it, regardless of the “kind” of function that was called. The type of the return value is the important characteristic.

    Ostensibly, the only reason you need to check if a function is async or not is as a sort of identity check to figure out if you should expect a promise returned or not. But that is a brittle and unreliable sort of assumption, since getRecord(..) above would fail the check but still returns a promise.

    Try to write code so that it’s obvious and reliable, regardless of function kind, whether a promise or immediate value will be returned.

    • I guess I should have mentioned that I’m not advocating that this is the way to know if you’re receiving a promise or not — just looking to see if the function was declared as async.

  3. Jaime

    If you need to be “defensive” with the returned value of a function, you can also wrap the returned value with Promise.resolve() this way:

    Promise.resolve( unknownFunction(/* args needed */) ).then( value => {
       /* whatever you need to do with the value */
    } );
    

    and that only in the case of consuming transpiled code but your own code can’t use await. In the case of full native async/await environment, await value works even if the value is not a Promise, so there’s no need to know is function is async or not.

  4. Stev0

    Wow, slammed for offering a potential way to meta code async and await. Thanks for the nuggets David. Sure in a perfect world where you got the write the program from the ground up I agree this is not a needed step. But we don’t live in a perfect world. When you get a project full of callbacks and need to switch between async and callbacks, knowing if a method is async is a very necessary step in lieu of performing a potentially massive refactor.
    I suppose it just gets to me when coders give unsolicited advice without understanding context. Code isn’t written in a vacuum.

  5. David

    There is definitely a use for this stuff.

    I’ve had to do this in the past for using decorators, as the decorator had a check that could be used on any function, but the descriptor value had to be set to specific types of functions (generator, async, normal, etc.) or else it would break the decorated method.

  6. You can have something like this as well:

    const AsyncFunction = (async () => {}).constructor;
    const GeneratorFunction = (function* () {}).constructor;
    
    const isAsyncFunction = value => value instanceof AsyncFunction;
    const isGeneratorFunction = value => value instanceof GeneratorFunction;
    
    isAsyncFunction(async () => {}); // true
    isGeneratorFunction(function* () {}); // true
    

    And also a shorter version with pretty much the same logic you have:

    const isAsync = myFunction[Symbol.toStringTag] === "AsyncFunction";
    

    Cheers!

  7. TommyO

    I’m a couple of years late, but I’m glad I found this. Too bad reception was so harsh. This provides the answer I *think* I need.

    I’m refactoring an old library that both accepted a callback and would return a promise. Although that was pretty convenient, it made for some pretty ugly gymnastics in each class method in order to check for the callback and shift around optional parameters. My theory is to only write async methods for the refactored version, but to supply a Proxy that could be used to wrap a class and convert all async methods to support a callback as well. For backwards compatibility simply wrap your instance in the Proxy.

    This seems like it provides the missing piece I need.

  8. Hannah Roksanne

    Just food for thought for any readers:

    You can await literally anything in JS.

    await 100
    await null
    await someAsyncFunction()
    await someNonAsyncFunction()
    await (new Promise((resolve) => resolve()))
    

    You can even create a getter that returns a promise and await it.

    const foo = {
      get usersDogsName() {
        return new Promise((resolve) => {
          fetch('/users/12345/dogsName')
            .then(response => response.json())
            .then(resolve)
        })
      }
    }
    
    await foo.usersDogsName
    

    … Or await a getter that is not asynchronous. (I guess it is worth adding for clarity.)

    const bar = {
      get age() {
        return user.age
      }
    }
    
    await bar.age
    

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!