There are some mismatched design patterns in your use of promises and asynchronous functions:
- Unless you need to extract a value from a promise or asynchronous function, or want to catch the promise rejection of a server side function in the server logs there is no need to wrap your asynchronous code in a
context.async
. - You are passing the (undefined) result of calling
console.log
to the error handling part of the callback. This is problematic and will result in unpredictable behaviour. - Ditto for your promise result, you are passing the (undefined) result of
console.log
to a eventually a return statement. Again more unpredictable behaviour. - Pick either
return Promise
orasync function
for your design pattern, not both. I personally prefer the older promise chaining as it forces me, as a developer, to think explicitly about asynchronous dependencies and orders of operation.
I would refactor your code to stick to one design pattern. For example using promise chaining:
function(instance, properties, context) {
// Start (writes first)
console.log("Start");
// Process (writes third)
instance.data.whiteboard.board.get()
.then((s) => { console.log(s); })
.catch((r) => { console.log(r); });
// End (writes second)
console.log("End")
}
Note: there are browser and Node.js dependent idiosyncrasies when parsing anonymous functions. Some are more tolerant of partial syntax than others. I always use fully “curly brace” anonymous syntax to guard against parser errors.
Server-side pattern using context.async
to mimic await
behaviour:
const mypromise = makeapromise();
const myresolved = context.async(
(callback) => {
mypromise
.then((result) => { callback(null, result); })
.catch((reason) => { callback(reason); });
}
);
Note: You can chain as many then
s and Promise.all
s or Promise.any
s together outside of context.async
before finally extracting a value with context.async