-
Notifications
You must be signed in to change notification settings - Fork 1
Description
I think, passing context as second parameter is wrong. API can't be scaled. For example, I want to support SharedArrayBuffer and need to pass it as third parameter for existing API. Maybe later, some additional parameters passed as fourth, fifth, e.t.c parameters.
Need to pass options object as second parameter and it can be scaled in more mature way.
Also, I think context, inspired from microjob, has ugly design:
Lines 58 to 66 in 95c554d
| for (const key in context) { | |
| if (!context.hasOwnProperty(key) || !context[key]) continue | |
| definition += `const ${key} = ${JSON.stringify(context[key])};\n` | |
| } | |
| const routineStr = ` | |
| async () => { | |
| ${definition} | |
| return await (${handler.toString()})() | |
| } |
Maybe need to deprecate it and implement simple data, which received as parameter on "go function":
go(function({data}) {
console.log(data.test) // 5
}, {data: {test: 5}})It solution so friendly with TypeScript type inference via generics.
Also JSON.stringify(data) more performant instead it:
for (const key in context) {
if (!context.hasOwnProperty(key) || !context[key]) continue
definition += `const ${key} = ${JSON.stringify(context[key])};\n`
} Also exists problem with dynamic function body:
async () => {
${definition}
return await (${handler.toString()})()
}
And eval of it can't be cached for high-load purpose applications and V8 JIT can't properly optimise it.