[Runtime field editor] Add server side for preview functionality

[sebelga]

This PR contains the core logic of the preview functionality of runtime fields inside the index pattern field editor.
It does not contain any UI yet so I output for now the result in the browser console.

How to test

• Add Kibana sample data logs
• Navigate to the index pattern management and select the sample data logs index pattern
• Click on "Add field" and open the Chrome dev tools to see the console
• Give a name to the field (e.g "foo")
• Enable the "Set value" toggle and add a script (e.g. emit("bar"))
• You should see the field preview in the console

Field preview: {
    "key": "foo",
    "value": "bar"
}

• Now update the script with the following where we read data from the index pattern document

Long bytesToGB = doc['machine.ram'].value / 1073741824;

emit(bytesToGB + 'GB');

• You should see the updated preview

Field preview: {
    "key": "foo",
    "value": "8GB"
}

Notes on implementations

Added <FieldEditorProvider />

To avoid property drilling I've added a fieldEditorContext to pass down services and context value to components down the tree. In this PR I haven't modified the existing code to reduce the amount of changes. In a following PR I will refactor to code to make use of the new context.

New top level __jest__ folder

In order to follow the pattern put in place in all of our apps I have created a top level __jest__ folder to add the component integration tests. Now that we have server side endpoint to test, the helpers will help mock the HTTP request response easily and test different scenarios in the UI.
In a following PR I will refactor the current component integration tests and move them to this folder.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[elasticmachine]

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

[sebelga]

@elastic/kibana-operations I had to update the plugin size limit as we have a tech debt on the field editor and need to change how we expose the field format editors to other plugins so make it lazy loaded instead of eagerly @mattkime . Do we know how many plugins currently use the public interface of the index pattern field editor to access the field format editors?

[sebelga]

@elasticmachine merge upstream

[sebelga]

@elasticmachine merge upstream

[mattkime]

@sebelga We should definitely lazy load the field format editor. I'm not aware of any use cases where it isn't used as part of the index pattern field editor but I might be misunderstanding your question.

#100366

[sebelga]

@mattkime You've exposed the fieldFormatEditors publicly for other plugins (https://github.com/elastic/kibana/blob/master/src/plugins/index_pattern_field_editor/public/plugin.ts#L41) So I wondered which plugin currently make use of it to know the impact of exposing an async loader instead of the format editors directly. And if no plugin use the format editors maybe we could remove it from the public interface?

[sebelga]

@elasticmachine merge upstream

[mattkime]

So I wondered which plugin currently make use of it to know the impact of exposing an async loader instead of the format editors directly. And if no plugin use the format editors maybe we could remove it from the public interface?

I haven't taken a look through the code but I know that its important to expose it for third party plugins. Custom field formatters are one of the most common reasons to create a third party plugin.

[sebelga]

@elasticmachine merge upstream

[cjcenizal]

Nit: I think in our other plugins we've tended to inject the handleEsError dependency, so line 31 would be something like this:

export const registerFieldPreviewRoute = ({ router, lib: { handleEsError } }: RouteDependencies): void => {

Not a blocker but it will make the code a little more consistent and would make it easier to mock this dependency if we ever write unit tests for these route handlers.

[sebelga]

Yes I remember that's the pattern I introduced in our plugins. I am not planning in adding unit tests for API route handlers as I tend to prefer integration tests for them.
I might update it though in future PR for the sake of alignement. 👍

[mattkime]

We should probably look at breaking out field format editors into its own plugin.

[mattkime]

code runs well, looks good!

[sebelga]

Thanks for the review @mattkime and @cjcenizal !

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: c11b273
• Storybooks Preview

History

• 💚 Build #127056 succeeded c11b273
• 💚 Build #126697 succeeded 0e143e8
• 💚 Build #126499 succeeded 5ba6755
• 💔 Build #126489 failed 80f169f
• 💔 Build #126388 failed 7166f11

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