[Mappings editor] Add UI/UX to mappings core

[sebelga]

This PR adds the stylings + improvement on the UX to the Core of the mappings editor. It contains all the suggestions from @cjcenizal in #47335

Child field vs Multi-field

A child field is a field that belongs to an object, it is one of the properties of an object or nested type. A multi-field is different. It is not a property of the field. It is the same field but indexed differently (e.g. a text field can also be indexed as keyword for aggregation or a text field can be indexed as another text type but with a different analyzer).

To make the difference clear to the user, we worked with @mdefazio to have a different UI when the field is a multi-field vs if it is a property of an object (toggle on the left of the field vs having to click on the count of multi-fields to expand the fields. Also, the multi-field has a "link" icon on its left instead of a "L" bullet list, and multi-fields are separated by dash instead of a solid line.

The current implementation is not the final design from Michael, which is this one:

But, as the <EuiBadge /> does not allow a counter, we want to validate first if the UX makes sense before spending time extending the badge component.

What to test

• When we fill the "name" in the create form, clicking outside sends the form and adds the field to the document
• If no "name" has been introduced in the field, clicking outside the form closes the create field form. Unless there are no fields added in the document. In that case, the form is always visible. Clicking "next" should not throw an error.
• When adding or editing a multi-field, the object and nested type should not be available in the select dropdown as those are not valid types for multi-field.
• We should not be able to nest multi-field. So, a "text" multi-field should not have the "Add multi-field" button visible when hovering.
• If we delete a field that either has child fields or multi-fields, a modal should open to confirm the deletion.
• If we change the "type" of field from "text" to anything else but "keyword" and if the field has multi-fields, a modal should open to confirm the type change. And vice versa (from "keyword" to anything else but "text").
• If we change the "type" of the field from "object" to anything else but "nested" and if the field has child fields, a modal should open to confirm the type change. And vice versa (from "nested" to anything else but "object").
• When editing a field, the field should be highlighted in the main view and the full path to the field should appear in the flyout header.

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: 72620fc

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: a5c7e9e

[mdefazio]

Looks good, just a few small SCSS tweaks:

• There are a few places in the ul.tree that uses 'em's instead of EUI variables.
• I think changing the dark border (which was in the mockup, sorry) to $euiBorderThin might make sense
• Perhaps we change the background color for the create wrapper to $euiColorLightestShade
• The flyout might need to be wider, or we may need to look at a different model for handling the type + subtype dropdowns in the edit view.

One larger change would be to keep the arrows on the left for collapse/expand for both nested children and multi-fields. Then we are keeping the same patter for showing and hiding. Could perhaps also try keeping the space for the arrow by default so there's not a jump in indentation when adding a child.

[jloleysens]

Left some non-blocker comments - have to test locally still. For some reason I'm getting a OOM state when starting Kibana locally on this branch.

[jloleysens]

Very elegant!

[jloleysens]

I'm not entirely clear on why this is need - as I understand it the byId object is a flat mapping on the tree so not sure what we gain by copying the array on another id on the same object and how this change result in the update?

[sebelga]

You are right, the logic had some complexity because of some memoization down the component tree. I updated the logic and removed the need of those non-intuitive array updates. Thanks for pointing this!

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: 25b006c

[jloleysens]

Tested all the points mentioned in description and everything works as expected.

The only UX point I'd like to add is perhaps showing the shortcuts on hover to open another field editor (collapsing the current one open the other one). So on hover of the field below in the picture that edit controls on the right would show. Just a suggestion.

[sebelga]

Thanks for the review @mdefazio and @jloleysens ! I have made all your recommended changes.

I will merge this PR to the feature branch so I can update my current working branch. Would you mind having a look at the feature branch and confirm the design and behaviour is OK?

The only UX point I'd like to add is perhaps showing the shortcuts on hover to open another field editor (collapsing the current one open the other one). So on hover of the field below in the picture that edit controls on the right would show. Just a suggestion.

It was a design decision to not allow adding child or multi-field meanwhile we are in "create" or "edit" mode. But that was before the "ClickOutside" behaviour.
As this change might add some complexity, I prefer to defer it to later and add it as an improvement . 👍

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: e03962d

[mdefazio]

This looks good to me!

[snide]

Hey @sebelga I see some CSS stuff in here that could be improved. I'll give you a PR to review, but some pointers from the sass docs.

1. Follow the naming schema rules.
2. Don't use pixel values 4px = $euiSizeXS...etc
3. prefix your component to avoid conflicts in Kibana
4. Don't use naked selectors like div, ul...etc.

An example of why this can be important. You have a naked ul.tree in use here. Who knows who else is using a class name like that. There's a lot of devs in kibana, and unfortunately kibana's css spills globally.

[sebelga]

Thanks for the review @snide

I kind of followed all the recommendations you mention aside from 1 exception here and there it seems 😊

Follow the naming schema rules.

Are you referring to using camel case for the class names?

[mdefazio]

Yes, I believe so... appBlockItem__eleMent or appBlockItem--modiFier