Add support for runtime field types to mappings editor.

[cjcenizal]

Fixes #77110

To test, add a runtime field to an index template's mappings via the UI or via Console like so:

PUT /my-index/_mappings
{
    "properties" : {
        "day_of_week" : {
            "type" : "runtime",
            "runtime_type" : "keyword",
            "script" : {
                "source" : "emitValue(doc['timestamp'].value.dayOfWeekEnum.getDisplayName(TextStyle.FULL, Locale.ROOT))"
            }
        }
    }
}

Release note

Index templates can now be configured with runtime fields in their mappings.

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)

[cjcenizal]

Note that these docs don't exist yet.

[alisonelizabeth]

Should we hold off on adding a value then? Or are we confident the doc url will eventually be /runtime_field.html?

[alisonelizabeth]

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.

For example:

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!

[alisonelizabeth]

nit: unnecessary fragment

[alisonelizabeth]

It's probably more appropriate to use the EuiComboBoxOptionOption type now (and at some point remove ComboBoxOption).

[alisonelizabeth]

Should we hold off on adding a value then? Or are we confident the doc url will eventually be /runtime_field.html?

[alisonelizabeth]

Can we just camelcase here so we don't need the eslint-disable?

const { type, runtime_type: runtimeType } = field;

[alisonelizabeth]

I might be missing something here, but is this necessary? I don't see it being used anywhere.

[cjcenizal]

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.

[alisonelizabeth]

Ah. Yeah, it isn't very clear, but I see that now after looking at the code_editor code. Thanks for adding the comment!

[cjcenizal]

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?

[alisonelizabeth]

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?

[alisonelizabeth]

Ah. Yeah, it isn't very clear, but I see that now after looking at the code_editor code. Thanks for adding the comment!

[cjcenizal]

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?

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.

Is "...use the text data type" and "...use the IP range data type" still relevant in the context of runtime fields?

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?

[cjcenizal]

@elasticmachine merge upstream

[alisonelizabeth]

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.

(in this view:)

---

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.

[cjcenizal]

@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.

[sebelga]

@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.

[cjcenizal]

Great idea, @sebelga! Done.

[sebelga]

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 stack var in your case) to change the layout depending of the width of the parent.

This would allow us to create components with a layout that adapts to wherever they are thrown in.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 1b01e7e

Metrics [docs]

@kbn/optimizer bundle module count

id	value	diff	baseline
indexManagement	508	+5	503

async chunks size

id	value	diff	baseline
indexManagement	1.6MB	+8.6KB	1.6MB

page load bundle size

id	value	diff	baseline
indexManagement	122.8KB	+158.0B	122.6KB

History

• 💔 Build #76239 failed 3ac63a6
• 💔 Build #76232 failed 00573c153579d9cbe65509e1ab297ee9df7a8f79
• 💔 Build #76039 failed 8a53f68
• 💔 Build #76036 failed 9af93bc
• 💚 Build #74653 succeeded ef9e325

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream