Currently, we have the module type in our GraphQL schema which contains functions that wrapper devs would implement but unlike plugin where plugin devs can easily extend the generated IModule interface, In the case of the wrapper, wrap dev needs to define the global functions with appropriate args, and return type. It would be more developer-friendly if we also provide an interface that developers can extend and provide an implementation for.
Let's take an example of a simple wrapper with the following schema:
type Module {
simpleMethod(arg: String!): String!
}
Now let's see how the codegen and wrap devx. would look like for Assemblyscript dev.
Here's how generated IModule interface would look for the simple wrapper with above schema
export abstract class IModule {
abstract simpleMethod(
args: Types.Args_simpleMethod
): string;
}
Here's how a wrap dev can implement the Module class by simply extending it
export class Module extends IModule {
simpleMethod(args: Args_simpleMethod): string {
return args.arg;
}
}
For method that needs to use env, env can be accessed with this.env readonly property.
Currently, we have the module type in our GraphQL schema which contains functions that wrapper devs would implement but unlike plugin where plugin devs can easily extend the generated
IModuleinterface, In the case of the wrapper, wrap dev needs to define the global functions with appropriate args, and return type. It would be more developer-friendly if we also provide an interface that developers can extend and provide an implementation for.Let's take an example of a simple wrapper with the following schema:
Now let's see how the codegen and wrap devx. would look like for Assemblyscript dev.
Here's how generated IModule interface would look for the simple wrapper with above schema
Here's how a wrap dev can implement the
Moduleclass by simply extending itFor method that needs to use env,
envcan be accessed withthis.envreadonly property.