-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Add support for runtime field types to mappings editor. #77420
Add support for runtime field types to mappings editor. #77420
Conversation
- Add tests for getTypeLabelFromField util.
Pinging @elastic/es-ui (Team:Elasticsearch UI) |
defaultMessage: 'Runtime', | ||
}), | ||
documentation: { | ||
main: '/runtime_field.html', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that these docs don't exist yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we hold off on adding a value then? Or are we confident the doc url will eventually be /runtime_field.html
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this @cjcenizal!
I left a few comments in the code.
I'm also wondering about the general workflow. For other field types that have required fields (such as alias
and token_count
), we require the required fields before adding it.
I think we probably want to do the same for runtime
field types. As it is, if I add a runtime
field type via the UI first, I see this:
I'm also able to proceed to the review step, but end up getting an error back from ES since runtime_type
and script
are both required.
For the runtime_type
parameter, I think we could possibly do something similar for numeric
and range
types, and have a subtype dropdown.
For example:
Let me know what you think!
|
||
export const RuntimeType = () => { | ||
return ( | ||
<> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: unnecessary fragment
)} | ||
singleSelection={{ asPlainText: true }} | ||
options={RUNTIME_FIELD_OPTIONS} | ||
selectedOptions={value as ComboBoxOption[]} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably more appropriate to use the EuiComboBoxOptionOption type now (and at some point remove ComboBoxOption
).
defaultMessage: 'Runtime', | ||
}), | ||
documentation: { | ||
main: '/runtime_field.html', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we hold off on adding a value then? Or are we confident the doc url will eventually be /runtime_field.html
?
|
||
export const getTypeLabelFromField = (field: Field) => { | ||
// eslint-disable-next-line @typescript-eslint/naming-convention | ||
const { type, runtime_type } = field; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just camelcase here so we don't need the eslint-disable
?
const { type, runtime_type: runtimeType } = field;
</MappingsEditorProvider> | ||
</AppContextProvider> | ||
</Provider> | ||
<KibanaReactContextProvider> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be missing something here, but is this necessary? I don't see it being used anywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CodeEditor
component used for editing the painless script requires it to provide uiSettings
, which is really unclear from the code. I'll add a comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah. Yeah, it isn't very clear, but I see that now after looking at the code_editor code. Thanks for adding the comment!
Thanks for the great review @alisonelizabeth! I incorporated your suggestions, and added a screenshot to the PR description to show how the UI now requires you to define the type before adding a runtime field. Could you please review again? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making the changes @cjcenizal! This is looking great.
script
also appears to be a required field. I understand the editor takes up some real estate, but I think it's important to make the user provide a value here before being allowed to submit the form. WDYT?
Also, I had a question about the copy for keyword
and ip
runtime types.
Is "...use the text data type" and "...use the IP range data type" still relevant in the context of runtime fields?
</MappingsEditorProvider> | ||
</AppContextProvider> | ||
</Provider> | ||
<KibanaReactContextProvider> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah. Yeah, it isn't very clear, but I see that now after looking at the code_editor code. Thanks for adding the comment!
7ef7643
to
90e1445
Compare
Whoops, good catch! Thanks for calling this out. I added validation. I had to surface the error message as a callout in addition to an error text, since the code editor is tall enough that it pushes the error text out of view on shorter screens. I think we need to solve this in the code editor component, e.g. by making it resize vertically to accommodate its content. I also update a couple other places where we were using callouts similarly, to follow the patterns shown in the EUI examples.
This is a great question. It's difficult for me to answer because I have a hard time understanding the user's intention when defining runtime fields in the index template. Ostensibly, if the user is defining or editing an index template, they have some level of control over the ingestion system, which includes the source of the documents being ingested and the ingest node pipeline used to process them. If this is the case, then they might be making decisions about how best to store, say, an IP. Maybe they're still trying to figure out the right design for their ingestion system, and maybe this text helps them realize they actually do want an IP range instead of an IP? Or maybe they started with the intention to define an IP range, but they didn't realize it's not yet supported by runtime fields? 🤷 I guess I'm not entirely sure if it's helpful, but I don't see how it hurts. Do you find it confusing? |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making the changes @cjcenizal. Great work!
I still wonder if the script
code editor should be present when initially adding the field (since it's required), but I'll leave that up to you.
This is a great question. It's difficult for me to answer because I have a hard time understanding the user's intention when defining runtime fields in the index template.
👍 I think it is fine to leave as-is. I was also wondering what the use case would look like.
@alisonelizabeth Good point. I was originally on the fence about adding the code editor to the "add field" component because I thought its height would disrupt the UX by causing content below it to jump around. But I think it's more important to be consistent with required parameters, so I added it in. I made the editor shorter, which I think helps (and also allowed me to remove the callout I had put in). I doubt these scripts will be so involved that they require as much height as I originally provided. |
…tor. Remove error callout.
00573c1
to
3ac63a6
Compare
@cjcenizal Can you explain why you are not using 2 columns for the required fields? I am surprised to see a huge select occupying the whole width. I understand in smaller screens those 2 will stack on top of another but on desktop? Or maybe have a described group with the "Emited type" on the left and the select on the right. Then the same for the script. |
Great idea, @sebelga! Done. |
Awesome thanks @cjcenizal ! I haven't played with it yet but maybe in the future for those scenarios, it would be nice to make use of the Resize observer and CSS (or maybe set the This would allow us to create components with a layout that adapts to wherever they are thrown in. |
💚 Build SucceededMetrics [docs]@kbn/optimizer bundle module count
async chunks size
page load bundle size
History
To update your PR or re-run it, just comment with: |
* master: (226 commits) [Enterprise Search] Added Logic for the Credentials View (elastic#77626) [CSM] Js errors (elastic#77919) Add the @kbn/apm-config-loader package (elastic#77855) [Security Solution] Refactor useSelector (elastic#75297) Implement tagcloud renderer (elastic#77910) [APM] Alerting: Add global option to create all alert types (elastic#78151) [Ingest pipelines] Upload indexed document to test a pipeline (elastic#77939) TypeScript cleanup in visualizations plugin (elastic#78428) Lazy load metric & mardown visualizations (elastic#78391) [Detections][EQL] EQL rule execution in detection engine (elastic#77419) Update tutorial-full-experience.asciidoc (elastic#75836) Update tutorial-define-index.asciidoc (elastic#75754) Add support for runtime field types to mappings editor. (elastic#77420) [Monitoring] Usage collection (elastic#75878) [Docs][Actions] Add docs for Jira and IBM Resilient (elastic#78316) [Security Solution][Resolver] Update @timestamp formatting (elastic#78166) [Security Solution] Fix app layout (elastic#76668) [Security Solution][Resolver] 2 new functions to DAL (elastic#78477) Adds new elasticsearch client to telemetry plugin (elastic#78046) skip flaky suite (elastic#78512) (elastic#78511) (elastic#78510) (elastic#78509) (elastic#78508) (elastic#78507) (elastic#78506) (elastic#78505) (elastic#78504) (elastic#78503) (elastic#78502) (elastic#78501) (elastic#78500) ...
…tic#77420)" This reverts commit 0dc89cb.
…r. (elastic#77420)" (elastic#79611)" This reverts commit e01d538.
…into feature/task_manager_429 * 'feature/task_manager_429' of github.com:elastic/kibana: (158 commits) Add license check to direct package upload handler. (#79653) [Ingest Manager] Rename API /api/ingest_manager => /api/fleet (#79193) [Security Solution][Resolver] Simplify CopyableField styling and add comments (#79594) Fine-tunes ML related text on Metrics UI (#79425) [ML] DF Analytics creation wizard: ensure job creation possible when model memory lower than estimate (#79229) Add new "Add Data" tutorials (#77237) Update APM telemetry docs (#79583) Revert "Add support for runtime field types to mappings editor. (#77420)" (#79611) Kibana request headers (#79218) ensure missing indexPattern error is bubbled up to error callout (#79378) Missing space fix (#79585) remove duplicate tab states (#79501) [data.ui] Lazy load UI components in data plugin. (#78889) Add generic type params to search dependency. (#79608) [Ingest Manager] Internal action for policy reassign (#78493) [ILM] Add index_codec to forcemerge action in hot and warm phases (#78175) [Ingest Manager] Update open API spec and add condition to agent upgrade endpoint (#79579) [ML] Hide Data Grid column options when histogram charts are enabled. (#79459) [Telemetry] Synchronous `setup` and `start` methods (#79457) [Observability] Persist time range across apps (#79258) ...
Fixes #77110
To test, add a runtime field to an index template's mappings via the UI or via Console like so:
Release note
Index templates can now be configured with runtime fields in their mappings.