[Lens] Allow visualizations to provide a dimension editor

[wylieconlon]

This sets up an optional function renderDimensionEditor which can be provided by visualizations to add extra configuration to a specific dimension. None of these new editors are added in the PR, but this sets up future work that would let the user change the axis, text alignment, color, or other visualization-specific styles.

When there is no editor registered, only one tab is shown:

Closes #67225

Checklist

Delete any items that are not applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[mbondyra]

@elasticmachine merge upstream

[mbondyra]

@wylieconlon good job! In this PR you're putting vis dimension editor right below the datasource dimension editor, don't we need a design for it for the placement? Another option would be separate tab. I am happy with merging it now and improving later.

[mbondyra]

I don't understand this test. Could you explain? 🙏

[wylieconlon]

It's testing another one of the edge cases in rendering, where the known layers don't match. This tests that when rendering layer first without any information about that ID, it doesn't throw errors.

[wylieconlon]

@mbondyra This placement is based on the design in #53663

[mbondyra]

tested if it doesn't break anything and with adding a very silly implementation of renderDimensionEditor:

  renderDimensionEditor (domElement,props ){
    render(<div>DimensionEditor</div>,
      domElement
    );
  },

[cchaos]

Based on the mock from #53660, the configurations need to be rendered to the right of the aggregations list, not below.

[wylieconlon]

@cchaos I don't think that's a realistic option because of the separate ownership of the two areas: The top section is entirely rendered by the datasource, and the bottom section is entirely rendered by the visualization.

[cchaos]

Then we will need to move quicker towards the next phase which is using Tabs to separate calculation and style/formatting concerns. The mock below shows two tabs, one where it's simply the aggregation and it's configurations, the other is for coloring and other stylistic options that are not necessarily tied to the aggregation type.

Actual content subject to change.

cc @AlonaNadler

I'm trying to avoid such a large void where there is no content and as the list of possible aggregations grows, that void will too.

[wylieconlon]

@cchaos Tabs are possible, but we aren't going to have very many options at the beginning. Imagine having a "Format & Style" tab with only one setting- is that acceptable?

[cchaos]

Yep! It's better for the user than moving UI a bunch.

[wylieconlon]

@cchaos done

[cchaos]

Thanks @wylieconlon! Now we have a good place to start adding in style customizations.

[cchaos]

Nit for BEM naming

Suggested change

	<div className="lnsVisualizationDimensionEditor">
	<div className="lnsLayerPanel__styleEditor">

[flash1293]

If I see this correctly, each visualization can only register a dimension editor for all dimensions at once, so if a visualization only needs this this in certain places (but not in all of them), an empty tab would be rendered, correct?

E.g. let's say we implement fitting function next, this makes only sense for the current x axis dimension, so the dimension editor would be empty for y axis dimensions, but the tab would still be rendered, right?

IMHO we should provide a way to not render a tab as well. Maybe having an optional property

shouldRenderDimensionEditor( props: VisualizationConfigProps<T> & {
  groupId: string;
  accessor: string; }): boolean;

as well.

[flash1293]

Maybe better: Another option would be to provide a list of groups you want the editor to show. That would discourage developers from showing the tab and hiding it based on configuration of the dimension (which would be confusing for end users).

[wylieconlon]

@flash1293 It sounds like we already have a solution for this, which is based on the way dimension groups are defined by the visualization. I can add something for this.

[flash1293]

@wylieconlon I see, making this part of VisualizationDimensionGroupConfig seems straightforward and like a good tradeoff

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 6833b1c

History

• 💚 Build #50581 succeeded 582105c
• 💔 Build #50510 failed 7658cf1
• 💔 Build #50452 failed 810d7cc
• 💔 Build #50429 failed 4aecbda
• 💚 Build #50262 succeeded 5b89017

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