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

Move Expression typings from Canvas to OSS Interpreter #36960

Closed
wants to merge 114 commits into from

Conversation

lukeelmers
Copy link
Member

@lukeelmers lukeelmers commented May 23, 2019

Summary

This is a first pass at moving the Canvas Expression Function types that @clintandrewhall worked on over to OSS so they can be exported from the interpreter for use by other plugins.

Reviewers: It's probably easiest to follow this by looking at each of the commits in order.

Usage / Testing

import { ExpressionFunction } from 'plugins/interpreter/types';
// ^^ I still need to verify that this webpack alias works in typescript from x-pack

const name = 'myfunc';

interface Context {
  type: 'whatever'; // in most cases you'll be importing Context from elsewhere
}

interface Arguments {
  foo: boolean | null;
}

interface Return {
  type: 'whatever'; // in most cases you'll be importing Return from elsewhere
}

export const myfunc = (): ExpressionFunction<typeof name, Context, Arguments, Return> => ({
  // function definition
});

Notes / Thoughts

  • Perhaps we should have an interpreter "types" base interface that individual types extend from when authoring their interfaces. Specifically we need to enforce that types have a type string value in their interface (which this generic relies on).
  • I haven't copied over some of the other generics (ContextFunction and NullContextFunction) because this all seemed to work with one unified generic... but I may be missing edge cases so @clintandrewhall let me know if I'm missing anything!
  • Next steps if this checks out will be: converting interpreter functions to use the new generic, making sure all types have interfaces defined, removing any types from canvas that this replaces
  • It may make more sense to re-export from the data plugin now (where this will live long term), instead of interpreter

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@lukeelmers lukeelmers changed the title Move typedefs for Expressions to OSS Move Expression typings from Canvas to OSS Interpreter May 23, 2019
@lukeelmers lukeelmers added :AppArch Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas Feature:ExpressionLanguage Interpreter expression language (aka canvas pipeline) review labels May 23, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-arch

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-canvas

@lukeelmers
Copy link
Member Author

I'll mark as ready to review for now, and we can discuss whether (once this is approved) we should include all of the updates in Canvas in this PR, or a subsequent one.

@lukeelmers lukeelmers marked this pull request as ready for review May 23, 2019 16:02
Copy link
Contributor

@chrisdavies chrisdavies left a comment

Choose a reason for hiding this comment

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

LGTM w/ possible tweaks. There are a few places where 'any' or 'object' is used, and 'unknown' might be more appropriate. Other than that, this looks great.


interface Column {
id: string;
name: string;
Copy link
Contributor

Choose a reason for hiding this comment

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

Does the column not contain any type information? That'd be pretty handy to have in a number of situations. (e.g. type: 'string')

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think so -- kibana_datatable is just the tabified data format, e.g.

{
  columns: [{ id: 'foo', name: 'Foo Col' }],
  rows: [{ foo: 'bar' }, { foo: 'baz' }],
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Chris, yes it'd be handy, it's not present at the moment, but typed table attribs had come up in discussion. For example, in the context of TS, it could warn that one wants to multiply a numeric column with an alpha column, or filter a time attribute represented as milliseconds since epoch with a range that represents time as days since epoch (ie. the physical type matches but the attribute domains have mismatched semantics).

Also, semantic types would be great for something like.... helping determine Kibana Lens options :-) For example, if an editor knew that those numbers represent time in milliseconds, then appropriate time filters etc. can be added (example is made up, only to illustrate that physical, easy to infer types such as numbers don't help a downstream, uncoupled consumer very much). On the demo day prez for shareable dataviz I touched on using attribute types as a goal, and super early steps.

Copy link
Contributor

Choose a reason for hiding this comment

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

@chrisdavies ^ I should've used the handle

/**
* Utility type: extracts returned type from a Promise.
*/
export type UnwrapPromise<T> = T extends Promise<infer P> ? P : T;
Copy link
Contributor

Choose a reason for hiding this comment

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

My brain hurts!

Copy link
Member Author

Choose a reason for hiding this comment

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

Clint was already using this in a generic somewhere, so I just extracted it as a utility. Unfortunately I can't take credit for authorship xD

Use case is when you have a type that may or may not be returned from a Promise -- you can use this and then you don't need to worry about whether the promise is there or not.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I understood it. It just took a bit of staring. I was just reminded of my experience learning Haskell a few years back. Hence, the aching brain. :)

@elasticmachine
Copy link
Contributor

💔 Build Failed

@lukeelmers
Copy link
Member Author

Caused by: org.elasticsearch.common.settings.SettingsException: The configuration setting [xpack.security.authc.realms.oidc.oidc1.rp.client_secret] is required

I think this is an unrelated issue that was fixed on master. Will rebase & push.

@lukeelmers lukeelmers force-pushed the feat/interpreter-types branch from 9e3756f to 248d0ed Compare May 23, 2019 22:30
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@ppisljar
Copy link
Member

i tried moving tagcloud fn over to TS, everthing seems to work, i am only missing types for Render type.

…ar intervals (elastic#36081)

* auto interval

* [TSVB] Rollup Search - 'auto' interval is not working for Rollup Jobs which were created in Calendar intervals

* [TSVB] Rollup Search - 'auto' interval is not working for Rollup Jobs which were created in Calendar intervals

* fix issue

* fix broken tests

* fix pr comments

* fix pr comments
XavierM and others added 8 commits May 29, 2019 13:33
…#37281)

* fix dataprovider query when the filed is a timestamp

* review II

* review III
* [feat] create additional http servers

allow for additional http servers to be created, tracked and returned

* respond to pr feedback

* tweak test

* update documentation

* destructure port, remove unnecessary imports

* [fix] export correct type

* [feat] expose createNewServer to plugins

* [fix] respond to pr feedback

* todo: add schema validation & integration test

* use reach

* [fix] use validateKey to validate partial

* [fix] change config shadowing

* check kibana port & prevent shadowing

* centralize start/stop for servers, add integration test

* remove unnecessary property

* never forget your await

* remove option to pass config into start

* fix pr feedback

* fix documentation

* fix test failures
* Add renovate.json

* Update and rename renovate.json to renovate.json5

* Update renovate.json5

* Update renovate.json5

* extend the base config

* remove enabled:false

* skip the part limiting managers, we point to specific package.json files instead

* try to disable updating all but eslint packages

* nest npm specific config

* fix syntax error

* bad copy job

* tweak labels

* disable update requests for `@kbn/` packages

* stop overriding rangeStategy

* extend package.json selectors

* add a couple more package.json files
typeof null === 'object', so add an explicit check for null
* Fix formatdate not allowing strings

* Addressing Feedback
@lukeelmers lukeelmers requested review from a team as code owners May 29, 2019 23:26
@lukeelmers lukeelmers requested a review from a team May 29, 2019 23:26
@lukeelmers lukeelmers requested a review from a team as a code owner May 29, 2019 23:26
@lukeelmers
Copy link
Member Author

ugh. sorry for the ping everyone 👋

you can safely ignore this

@lukeelmers
Copy link
Member Author

To spare y'all from further updates, I'm going to go ahead and close this one in favor of #37438.

@lukeelmers lukeelmers closed this May 29, 2019
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

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) review Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas
Projects
None yet
Development

Successfully merging this pull request may close these issues.