I have to pass a function to another function, and execute it as a callback. The problem is that sometimes this function is async, like:
async function() {
// Some async actions
}
So I want to execute await callback() or callback() depending on the type of function that it is receiving.
Is there a way to know the type of the function??
Native async functions may be identifiable when being converted to strings:
asyncFn[Symbol.toStringTag] === 'AsyncFunction'
Or by AsyncFunction constructor:
const AsyncFunction = (async () => {}).constructor;
asyncFn instanceof AsyncFunction === true
This won't work with Babel/TypeScript output, because asyncFn is regular function in transpiled code, it is an instance of Function or GeneratorFunction, not AsyncFunction. To make sure that it won't give false positives for generator and regular functions in transpiled code:
const AsyncFunction = (async () => {}).constructor;
const GeneratorFunction = (function* () {}).constructor;
(asyncFn instanceof AsyncFunction && AsyncFunction !== Function && AsyncFunction !== GeneratorFunction) === true
Since native async functions were officially introduced to Node.js in 2017, the question likely refers to Babel implementation of async function, which relies on transform-async-to-generator to transpile async to generator functions, may also use transform-regenerator to transpile generator to regular functions.
The result of async function call is a promise. According to the proposal, a promise or a non-promise may be passed to await, so await callback() is universal.
There are only few edge cases when this may be needed. For instance, native async functions use native promises internally and don't pick up global Promise if its implementation was changed:
let NativePromise = Promise;
Promise = CustomPromiseImplementation;
Promise.resolve() instanceof Promise === true
(async () => {})() instanceof Promise === false;
(async () => {})() instanceof NativePromise === true;
This may affect function behaviour (this is a known problem for Angular and Zone.js promise implementation). Even then it's preferable to detect that function return value is not expected Promise instance instead of detecting that a function is async, because the same problem is applicable to any function that uses alternative promise implementation, not just async (the solution to said Angular problem is to wrap async return value with Promise.resolve).
From the outside, async function is just a function that unconditionally returns native promise, therefore it should be treated like one. Even if a function once was defined async, it can be transpiled at some point and become regular function.
In ES6, a function that potentially returns a promise can be used with Promise.resolve (lets synchronous errors) or wrapped Promise constructor (handles synchronous errors):
Promise.resolve(fnThatPossiblyReturnsAPromise())
.then(result => ...);
new Promise(resolve => resolve(fnThatPossiblyReturnsAPromiseOrThrows()))
.then(result => ...);
In ES2017, this is done with await (this is how the example from the question is supposed to be written):
let result = await fnThatPossiblyReturnsAPromiseOrThrows();
...
Checking if an object is a promise is a matter of a separate question, but generally it shouldn't be too strict or loose in order to cover corner cases. instanceof Promise may not work if global Promise was replaced, Promise !== (async () => {})().constructor. This can happen when Angular and non-Angular applications interface.
A function that requires to be async, i.e. to always return a promise should be called first, then returned value is checked to be a promise:
let promise = fnThatShouldReturnAPromise();
if (promise && typeof promise.then === 'function' && promise[Symbol.toStringTag] === 'Promise') {
// is compliant native promise implementation
} else {
throw new Error('async function expected');
}
TL;DR: async functions shouldn't be distinguished from regular functions that return promises. There is no reliable way and no practical reason to detect non-native transpiled async functions.
AsyncFunction !== Function is always false even though I have functions with keyword async passed as an argument to an it() spec. I am using Typescript by the way. Could you please take a look at this question and provide your insights. I have been trying so many different ways but didn't succeed yet. :( –
Sculpturesque AsyncFunction !== Function check is there to avoid false positives. There won't be true positives in transpiled code because async functions don't differ from regular ones in transpiled code. –
Acantho await, it works for promises and non-promises. This is what the last snippet in the answer shows. –
Acantho async, you can check that its return value is native promise (result instanceof Promise) or thenable (result && typeof result.then === 'function'). –
Acantho As long as only the native async functions are used (which is usually the case), I prefer this simple way:
theFunc.constructor.name == 'AsyncFunction'
theFunc = new class AsyncFunction extends Function {}. But transpiled async function doesn't, theFunc = () => __awaiter(void 0, void 0, void 0, function* () { }). –
Acantho === 'AsyncFunction' like what @theVoogie suggested? –
Aimeeaimil class AsyncFunction {} and break this but i get the point that it's unlikely –
Anxious [email protected] that class AsyncFunction {}; console.log(AsyncFunction.constructor.name) returns Function, because class is a sync function, not async one. Of cause, one cannot call AsyncFunction() (when it is a class) without new word, but the answer is correct to distinguish async function from sync one. –
Walters Function regardless the function type. –
Supremacist Both @rnd, and @estus are correct.
But to answer the question with an actual working solution here you go
function isAsync (func) {
const string = func.toString().trim();
return !!(
// native
string.match(/^async /) ||
// babel (this may change, but hey...)
string.match(/return _ref[^\.]*\.apply/)
// insert your other dirty transpiler check
// there are other more complex situations that maybe require you to check the return line for a *promise*
);
}
This is a very valid question, and I'm upset that someone down voted him. The main usecase for this type of checking is for a library/framework/decorators.
These are early days, and we shouldn't downvote VALID questions.
_ref won't be there. –
Acantho fn.constructor.name, which will be AsyncFunction for async functions. –
Delibes await semantics. It doesn't matter if a function is async in any practical scenario I'm aware of. async is just a function that unconditionally returns native promise - and should be treated like one. async can become transpiled at some point, this shouldn't ruin an app. For the scenario you describe it's correct for a wrapper to call a function and assert a value to be promise, not assert a function to be async. If it needs to prevent invalid handlers ASAP, this has to be enforced at design time with TS/Flow –
Acantho async check there, don't you? You have to be aware that client lib will make Angular users suffer because the framework requires async to be transpiled in order for change detection to work (and server lib will affect Electron+Angular apps). It's possible to use async for semantic purposes but I'd consider it a misuse, this is what decorators are for. Extra data in method names like you did with : is also common. It's surely needed for code analysis but that's a reasonable exception, not something that regular users look here for. –
Acantho async, then that's a good reason to not use Angular, frankly. Plenty of other frameworks, and modern vanilla JS, to pick from. As for what someone might use this for: I'm hardly a regular user, and yet I commented here because that's that SO post that Google found me when I was looking for a decent way to check for async-ness. Good stackoverflow answers help everyone, not just regular users ;) –
Delibes function(resolve, reject), async function() or Promise. The second two can be detected rather easily if a transpiler isn't involved. Once the transpiler gets involved, it's pretty much impossible to detect the difference between async and function(resolve, reject). Unfortunately, due to minification, the proposed solution is just shy of working. It's too bad that the transpiler didn't leverage a Promise pollyfill, which would have been easier to detect. :/ –
Grogshop In case you're using NodeJS 10.x or later
Use the native util function.
util.types.isAsyncFunction(function foo() {}); // Returns false
util.types.isAsyncFunction(async function foo() {}); // Returns true
Do keep all the concerns in mind from above ansers though. A function that just returns by accident a promise, will return a false negative.
And on top of that (from the docs):
Note that this only reports back what the JavaScript engine is seeing; in particular, the return value may not match the original source code if a transpilation tool was used.
But if you use async in NodeJS 10 and no transiplation. This is a nice solution.
It seems that await can be used for normal functions too. I'm not sure if it can be considered "good practice" but here it is:
async function asyncFn() {
// await for some async stuff
return 'hello from asyncFn'
}
function syncFn() {
return 'hello from syncFn'
}
async function run() {
console.log(await asyncFn()) // 'hello from asyncFn'
console.log(await syncFn()) // 'hello from syncFn'
}
run()
await will promisify normal fucntions –
Neaten Here is a short and useful approach provided by David Walsh in his blogpost:
const isAsync = myFunction.constructor.name === "AsyncFunction";
Cheers!
Short answer: Use instaceof after exposing AsyncFunction - see below.
Long answer: Don't do that - see below.
You can detect whether a function was declared with the async keyword
When you create a function, it shows that it's a type Function:
> f1 = function () {};
[Function: f1]
You can test it with the instanceof operator:
> f1 instanceof Function
true
When you create an async function, it shows that it's a type AsyncFunction:
> f2 = async function () {}
[AsyncFunction: f2]
so one might expect that it can be tested with instanceof as well:
> f2 instanceof AsyncFunction
ReferenceError: AsyncFunction is not defined
Why is that? Because the AsyncFunction is not a global object. See the docs:
even though, as you can see, it's listed under Reference/Global_Objects...
If you need easy access to the AsyncFunction then you can use my unexposed module:
to get either a local variable:
const { AsyncFunction } = require('unexposed');
or to add a global AsyncFunction alongside other global objects:
require('unexposed').addGlobals();
and now the above works as expected:
> f2 = async function () {}
[AsyncFunction: f2]
> f2 instanceof AsyncFunction
true
The above code will test whether the function was created with the async keyword but keep in mind that what is really important is not how a function was created but whether or not a function returns a promise.
Everywhere where you can use this "async" function:
const f1 = async () => {
// ...
};
you could also use this:
const f2 = () => new Promise((resolve, reject) => {
});
even though it was not created with the async keyword and thus will not be matched with instanceof or with any other method posted in other answers.
Specifically, consider this:
const f1 = async (x) => {
// ...
};
const f2 = () => f1(123);
The f2 is just f1 with hardcoded argument and it doesn't make much sense to add async here, even though the result will be as much "async" as f1 in every respect.
So it is possible to check if a function was created with the async keyword, but use it with caution because you when you check it then most likely you're doing something wrong.
async to know if it is doing some async/await operation inside but returning nothing. –
Dimenhydrinate then().catch() an async function, you try/await it instead. So yeah, you totally should check the function's type if you leitimately need to know whether it's async or not, but not by using instanceof: use fn.constructor.name instead. If it's AsyncFunction instead of Function, you know it's an async function. –
Delibes So I want to execute await callback() or callback() depending on the type of function that it is receiving.
You could always execute it with await and it will do the right thing:
async function main(callback) {
let result = await callback(); // even if callback is not async
// use 'result'
}
Is there a way to know the type of the function??
Maybe what you're actually interested in is the type of the result of the function. Dariusz Filipiak's answer is good but it can be even more concise:
async function main(callback) {
let result = callback();
if (result instanceof Promise) {
result = await result;
}
// use 'result'
}
You can assume at begin that callback is promise:
export async function runSyncOrAsync(callback: Function) {
let promisOrValue = callback()
if (promisOrValue instanceof Promise) {
promisOrValue = Promise.resolve(promisOrValue)
}
return promisOrValue;
}
and them in your code you can do this:
await runSyncOrAsync(callback)
which will solve your problem with unknowing callback type....
I always use Promises and async/await interchangeably, as they are basically the same.
Async/Await is used to work with promises in asynchronous functions. It is basically syntactic sugar for promises. It is just a wrapper to restyle code and make promises easier to read and use. Source: GeeksForGeeks
If you need a helper function to determine if a value is an asynchronous function, without invoking it, or if a value is a function that returns a Promise, you have arrived at the right post.
In this example I will present three different approaches.
This function can determine if a function was defined using the async keyword.
async function a() {}
const b = async () => {}
function isAsyncFunction(f: unknown): boolean {
return f && f.constructor.name === 'AsyncFunction'
}
This function can determine if a regular function returns a Promise. In order assess if the given function returns a Promise, we need to invoke the function and examine the returned value. To avoid multiple invocations of the same function, we can return the the aforementioned value if it's a Promise, and false if it's not.
function a() { return new Promise(() => {}) }
const b = () => new Promise(() => {})
function isPromiseFunction<T>(fn: any, ...params: any[]): Promise<T> | boolean {
const isFunction = fn && typeof fn === 'function'
const notAsyncFunction = fn.constructor.name !== 'AsyncFunction'
if (isFunction && notAsyncFunction) {
const value = fn(...params) || false
if (value && value.constructor.name === 'Promise') {
return value as Promise<T>
}
}
return false
}
Because both AsyncFunction and Promise are essentially the same, we can just check if they both return a Promise.
function isAsync<T>(fn: any, ...params: any[]): Promise<T> | boolean {
const isFunction = fn && typeof fn === 'function'
if (isFunction) {
const value = fn(...params) || false
if (value && value.constructor.name === 'Promise') {
return value as Promise<T>
}
}
return false
}
Asynchronous functions are faster and cleaner to validate, whereas promise functions need to be invoked in order to be validated.
await on a call to any function fundamentally changes the execution sequence, When await is applied to a sync function call, the result is that the async function within which the call is made will return an unresolved promise at the point of the await even though the called sync function has already completed. –
Coven Instead of testing if a function that you want to call efficiently is an async function (i.e. returns a Promise), you can call it without await, check if the returned value is a promise, and only then await it:
let result = someFunctionWhichMayBeAsync()
if (typeof result?.then === 'function') {
result = await result
}
This approach will work with genuine async functions, and anything which returns a Promise (or thenable. The only caveat is it could fail if a value is returned which has a .then method which is not actually a thenable (but so would calling await or Promise.resolve() unconditionally in that circumstance, so there isn't really anything better you can do).
FWIW it may not be any more performant than just awaiting the return value unconditionally, as checking the value of .then might be more expensive than the overhead of await - here's a benchmark.
© 2022 - 2024 — McMap. All rights reserved.
awaita non-promise, it automatically wraps it anyway) – Prohibitoryawaiton the call will unnecessarily introduce a promise wrapper around it and is, I guess, somewhat less efficient. – Coven