In this case the interface does not define context, but the implementing
service may use it as an optional argument:
interface IService {
add(a: number, b: number): number
}
class Service implements IService {
add(a: number, b: number, ctx?: IContext): number {
return a + b + ctx!.userId
}
}
A few notes:
1) The context higher-order function will be tedious to define - a lot
more typing than just an extra function argument.
2) As some methods do not require the context function, forgetting to
call it might introduce bugs (await fn will not error out), but
compile checks of the return value type might detect this
Possible solution is to go the GRPC way and allow only a single method
type as a parameter so all server-side method types would look like:
async fn(param: IParam, context: Context) {}
and all client-side method types would look like:
async fn(param: IParam) {}
However, This would deviate from the JSON-RPC standard which allows
multiple arguments to be passed in an array.
Alternatively, context could be passed as a first argument and then
filtered out:
type Arguments<T> = T extends (context: Ctx, ...args: infer A) => infer R
? A
: never
In this case, the type of Ctx would need to be known in advance. Will
have to think about this some more.
Typeorm loads all @Entities and decorator-defined relations into a
global variable, and thus makes it impossible to override already
defined variables.
Will have to think about how to disable this behaviour in case the user
of this library does not want to use predefined variables, but for now
we will use the predefined defaults.
