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

  • By
    CSS Animations Between Media Queries

    CSS animations are right up there with sliced bread. CSS animations are efficient because they can be hardware accelerated, they require no JavaScript overhead, and they are composed of very little CSS code. Quite often we add CSS transforms to elements via CSS during...

  • By
    JavaScript Promise API

    While synchronous code is easier to follow and debug, async is generally better for performance and flexibility. Why "hold up the show" when you can trigger numerous requests at once and then handle them when each is ready?  Promises are becoming a big part of the JavaScript world...

Incredible Demos

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.

  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.

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