Index pattern field editor

[sebelga]

This PR contains the reusable, embeddable everywhere, index pattern field editor. Currently, it is integrated into the index pattern management app. In future releases, it will be integrated into Discover, Lens, and any other app

The editor allows the user to

• Create and edit runtime fields
• Edit mapped fields (change the custom label, the format, or the popularity)

Examples

The examples below assume that you have added the "indexPatternFieldEditor" plugin to the required plugins list (in kibana.json). You then get back its API through the start contract.

Create / edit a field

const MyComponent = () => {
    const closeFieldEditor = useRef<() => void | undefined>();

    // Access the plugin through context
    const { indexPatternFieldEditor } = useAppDependencies();

    const openEditor = () => {
        closeFieldEditor.current = indexPatternFieldEditor.openEditor({
            // the only required option is the context in which the editor is being used
            ctx: {
                indexPattern,
            },
            // optionally you can also provide the following parameters:
            fieldName: 'fieldToEdit',
            onSave: (field) => {
                // handler to call once the field has been saved 
                // e.g. refreshFieldList();
            },
        });
    };

    useEffect(() => {
        return () => {
            // Make sure to close the editor when unmounting
            if (closeFieldEditor.current) {
                closeFieldEditor.current();
            }
        }
    }, []);

    return (
        <EuiButton onClick={openEditor}>Create field</EuiButton>
    );
}

Delete one or multiple fields

To delete one or multiple runtime fields there is a render props component that you can use.

// The `deleteFields()` handler that you get back lets you pass a single (`string`)
// or multiple (`string[]`) field names to delete.

const MyComponent = () => {
    const { indexPatternFieldEditor } = useAppDependencies();
    const { DeleteRuntimeFieldProvider } = indexPatternFieldEditor;

    return (
        <DeleteRuntimeFieldProvider indexPattern={indexPattern}>
            {(deleteFields) => (
                <EuiButton fill color="danger" onClick={() => deleteFields('myField')}>
                    Delete
                </EuiButton>
            )}
        </DeleteRuntimeFieldProvider>       
    );
}

How to test

• Navigate to the Stack management > Index pattern
• Click on one of your index patterns
• There should be a button to "Create field"
• Click on the button and start creating a field. The only required form field is the "name", al the others are optional.
• The painless script syntax is validated by executing a query against ES. You can try to pass invalid syntax and verify that you are not allowed to save the field.
• Once you save the field, it should appear in the table, along with any other field.
• You can now go to Discover and start using the field any way you want!

API

The complete API is documented in the README.md

Screenshots

Release note

There is a new field editor in the index pattern management app that lets you create (and edit) runtime fields, adding them to the index pattern field list.

[sebelga]

@elasticmachine merge upstream

[sebelga]

@elasticmachine merge upstream

[mattkime]

@elasticmachine merge upstream

[sebelga]

@elasticmachine merge upstream

[mattkime]

@elasticmachine merge upstream

[kibanamachine]

merge conflict between base and head

[mattkime]

@elasticmachine merge upstream

[sebelga]

@elasticmachine merge upstream

[sebelga]

@elasticmachine merge upstream

[kibanamachine]

merge conflict between base and head

[sebelga]

@elasticmachine merge upstream

[mattkime]

@elasticmachine merge upstream

[sebelga]

@elasticmachine merge upstream

[jloleysens]

@elasticmachine merge upstream

[jloleysens]

Works exactly described, great work @sebelga ! Great work 🍻! I spent a while playing around with this functionality, it is really exciting to see this come to life in the ES stack 👏🏻

I tested locally and wanted to share the following thoughts on the UX since I approached this with very little domain knowledge :), no blockers from my side however.

Mention of "runtime fields"

While creating/editing a "new field" I did not encounter the term "runtime field" until I reached this point. I'm not sure users coming from little/no domain knowledge will understand this term or the distinction it implies since there is not mention of it before this help text.

Consistency with use of "_source"

This is a nit, but in some places "_source" is presented as "code" text, and in others not. Should we make it just one or the other?

[sebelga]

Thanks for the review @jloleysens ! I fixed the inconsistency issue in #91477.

Regarding your comment about not mentioning runtime fields anywhere but in the helptext I prefer to leave that to @lockewritesdocs. It was deliberate to have "Create field" instead of "Create runtime field".

[lockewritesdocs]

Mention of "runtime fields"

While creating/editing a "new field" I did not encounter the term "runtime field" until I reached this point. I'm not sure users coming from little/no domain knowledge will understand this term or the distinction it implies since there is not mention of it before this help text.

@jloleysens, you make a good point! I agree that seeing the term runtime fields in a field description for the first time is a little jarring. I talked to @mattkime, and we're going to leave things as they are for now and continue this discussion elsewhere about whether to expose Kibana users to the concept of runtime fields at all, and how to get them information about writing Painless scripts when they need it.

[sebelga]

@elasticmachine merge upstream

[myasonik]

Looks like you added a lot of new UI! Any chance you can add some a11y tests to this? (Docs)

Will save you the trouble of having to go back and do this when QA goes through it later and makes a follow up ticket for you but you've forgotten all the context around your work. (Meta with many examples)

[mattkime]

@elasticmachine merge upstream

[sebelga]

The CI failure is due to a recent merged on master and a conflict in TS interface. I asked @qn895 to update their interface (63ac0f7#r47216005)

[mattkime]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: cacfe25
• Documentation Changes

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
data	704	705	+1
indexPatternFieldEditor	-	77	+77
indexPatternManagement	206	165	-41
total			+37

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
indexPatternFieldEditor	-	21.8KB	+21.8KB
indexPatternManagement	555.7KB	565.1KB	+9.5KB
total			+31.2KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
core	477.0KB	477.2KB	+111.0B
data	912.1KB	913.0KB	+946.0B
esUiShared	217.3KB	217.4KB	+75.0B
indexPatternFieldEditor	-	79.1KB	+79.1KB
indexPatternManagement	69.8KB	15.2KB	-54.6KB
total			+25.6KB

Unknown metric groups

@kbn/ui-shared-deps asset size

id	before	after	diff
kbn-ui-shared-deps.js	7.4MB	7.4MB	+192.0B

async chunk count

id	before	after	diff
indexPatternFieldEditor	-	1	+1

History

• 💔 Build #107185 failed 1593084
• 💔 Build #107107 failed b82e11f
• 💚 Build #106856 succeeded e32708d
• 💚 Build #106839 succeeded ca5cf22
• 💚 Build #106739 succeeded 864ae47

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

[flash1293]

It's not a strict requirement but would it be possible to expose the delete functionality outside of the render prop? Due to the structure of our components it would simplify the integration.

[sebelga]

@flash1293 We exposed it in the render props because it comes with the confirmation modal to let the user confirm he wants to delete the fields. We could expose the delete outside of the render props component but then you would have to implement the confirmation modal logic. Let us know