Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[skip-ci] POC: typings for expressions AST builder #62334

Closed
wants to merge 4 commits into from

Conversation

lukeelmers
Copy link
Member

Do not merge -- this is just an example

This shows a way you could enforce expression function types in an AST builder.

It requires each plugin registering an expression function to also add a property with the same function name to a shared ExpressionFunctionDefinitions interface which is exported from src/plugins/expressions.

Then in the AST builder's createFunction method, we can use the provided function name to infer the correct interface(s) from ExpressionFunctionDefinitions

@botelastic botelastic bot added the Feature:ExpressionLanguage Interpreter expression language (aka canvas pipeline) label Apr 2, 2020
Comment on lines +25 to +28
builder.createFunction('visualization', {
index: 'foo',
visConfig: '{}',
});
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will enforce that the provided args match the arguments interface for the visualization function

Comment on lines +72 to +77
// Add esaggs function to ExpressionFunctionDefinitions
declare module '../../../../expressions/public' {
interface ExpressionFunctionDefinitions {
esaggs: ExpressionFunctionEsaggs;
}
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The catch is that each plugin registering an expression function will need to do this. If the function is available on the server they will need to declare it there too. (Or if we end up moving toward common being a first-class citizen in plugins, they'll only have to do this once)

export interface ExpressionFunctionDefinitions {
// The property name should match the name of your function.
kibana_context: ExpressionFunctionKibanaContext;

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of the other functions provided by the expressions plugin would need to be added here too

Comment on lines +30 to +40
createFunction<K extends keyof ExpressionFunctionDefinitions>(
name: K,
args: ExpressionFunctionDefinitions[K] extends ExpressionFunctionDefinition<
infer Name,
infer Input,
infer Arguments,
infer Output,
infer Context
>
? Arguments
: never
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is where the magic happens. We are looking at the string provided in the first argument, and using it as the index for ExpressionFunctionDefinitions. Then we infer each of the params which were provided to the original ExpressionFunctionDefinition interface.

@lukeelmers lukeelmers mentioned this pull request Apr 7, 2020
7 tasks
@lukeelmers lukeelmers mentioned this pull request Apr 24, 2020
6 tasks
@lukeelmers
Copy link
Member Author

Closing as a final approach was worked out and merged as a part of #64395

@lukeelmers lukeelmers closed this Aug 6, 2020
@lukeelmers lukeelmers deleted the poc/ast-builder-types branch February 11, 2021 15:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:ExpressionLanguage Interpreter expression language (aka canvas pipeline)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant