-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Input Control visualization #13314
Input Control visualization #13314
Conversation
bf5a80b
to
0586962
Compare
jenkins, test this |
jenkins, test this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sending out first round of comments.
} | ||
|
||
handleToggleControlVisibility() { | ||
this.setState({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be:
this.setState(prevState => { isEditorVisible: !prevState.isEditorVisible });
} | ||
|
||
return ( | ||
<div className="sidebar-item"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about breaking this component down into something like EditorSummaryBar and EditorDetails? Might help pare this back a little bit, and neither of those components would need any state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure this gets you anything. With the above requested changes, control_editor is very straightforward.
render() { | ||
let editor; | ||
if (this.state.isEditorVisible) { | ||
editor = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about either making this a function outside render, or a separate component? e.g. getEditorContents() and then below could do
{ this.state.isEditorVisible && getEditorContents() }
super(props); | ||
|
||
this.state = { | ||
isEditorVisible: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about isEditorCollapsed?
<input | ||
className="kuiTextInput" | ||
type="text" | ||
value={this.props.controlParams.label} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should all have spaces inside the parens (and elsewhere in the file)
value={ this.props.controlParams.label }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure about that? From working in x-pack-kibana I know that from 6.1 onward there is an eslint rule enforcing no spaces inside of {}
.
https://github.com/elastic/kibana/blob/master/packages/eslint-config-kibana/.eslintrc.js#L89-L100
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoa you are right (https://github.com/elastic/x-pack-kibana/pull/2371 and #13323 did all the conversions), sorry for the misdirection @nreese and thanks for pointing that out @archanid. Looks like we switched it over to match the AirBnb style guide. I guess the react style guide should be updated because all of the examples in there use the old style of spaces inside.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I filed #13846 to keep track.
constructor(props) { | ||
super(props); | ||
|
||
this.loadOptions = this.loadOptions.bind(this); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fine, but just wanted to point out there is another way to do this that is even more concise:
import React, { Component } from 'react'; | ||
import Select from 'react-select'; | ||
|
||
export class IndexPatternSelect extends Component { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TSVB has a similar Index pattern field, except that it's not a drop down and can accept any index pattern on the fly. Unless there is a specific reason for the differences, I think we should try to do the same - either let them enter in any custom index pattern here, or adjust TSVB to be a drop down like this. @simianhacker or @snide -- any thoughts on this?
I was going to suggest this go into the uiFramework but because of the K7 stuff in progress, it might not be worth it right now. Just when K7 gets here, we'll want to migrate over to use those control components.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TSVB will probably always be adhoc because there are a lot of users with dashboards that depend on the current behavior; I don't want to take that away from them.
import React, { Component } from 'react'; | ||
import Select from 'react-select'; | ||
|
||
export class IndexPatternSelect extends Component { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can be a functional, stateless component: https://github.com/elastic/kibana/blob/master/style_guides/react_style_guide.md#prefer-stateless-functional-components-where-possible
import React, { Component } from 'react'; | ||
import Select from 'react-select'; | ||
|
||
export class FieldSelect extends Component { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This component looks like it could be generalized for the uiFramework as well - e.g. FilterableSelect.
@snide - what's your take on components like this. Would you prefer they get moved into the uiFramework ala k6, or should we hold off for now due to incoming k7?
import { IndexPatternSelect } from './index_pattern_select'; | ||
import { FieldSelect } from './field_select'; | ||
|
||
export class ListControlEditor extends Component { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make stateless function. I thought we had eslint checks for this recently put it place, but maybe it's only turned on in the uiFramework... CJ would know but I don't want to tag him on paternity leave.
Few other files/components I see that should be in the functional stateless variety.
One more thing - can you add jest tests for all the react components? |
Label | ||
</label> | ||
<div className="kuiSideBarFormRow__control kuiFieldGroupSection--wide"> | ||
<input |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please label this input
with the above label
(see accessibility style guide) using htmlFor
in React.
{this.props.controlTitle} | ||
</span> | ||
<div className="vis-editor-agg-header-controls kuiButtonGroup kuiButtonGroup--united"> | ||
<button |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This button
is missing an aria-label
, that describes it (since it doesn't have any textual content).
> | ||
<i aria-hidden="true" className="fa fa-chevron-down" /> | ||
</button> | ||
<button |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This button
is missing an aria-label
, that describes it (since it doesn't have any textual content).
Field | ||
</label> | ||
<div className="kuiSideBarFormRow__control kuiFieldGroupSection--wide"> | ||
<Select |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please label this Select
(you can set an id
with inputProps={{ id: 'yourId' }}
) with the above label.
Index Pattern | ||
</label> | ||
<div className="kuiSideBarFormRow__control kuiFieldGroupSection--wide"> | ||
<Select.Async |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please label this Select
(see other comment).
Size | ||
</label> | ||
<div className="kuiSideBarFormRow__control kuiFieldGroupSection--wide"> | ||
<input |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please label this input
with the above label
(see other comment).
Step Size | ||
</label> | ||
<div className="kuiSideBarFormRow__control kuiFieldGroupSection--wide"> | ||
<input |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please label this input
with the above label
(see other comment).
|
||
<div className="kuiSideBarFormRow"> | ||
<div className="kuiSideBarFormRow__control kuiFieldGroupSection--wide"> | ||
<select |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please provide a label (e.g. via aria-label
) for this select
.
<FormRow | ||
label={this.props.control.label} | ||
> | ||
<Select |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please label
this Select
(see other comment).
label={this.props.control.label} | ||
> | ||
<div className="inputRangeContainer"> | ||
<InputRange |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please label this element, using aria-labelledby
on the InputRange
and set this to the id
of the label in FormRow
(I guess that needs some modifications.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have general hesitations to us adding another method of selecting/specifying an index-pattern with this visualization. We have the "traditional" method, and the TSVB free-form method, the Timelion method, and now this.
I'm wondering if this is intertwined with us defining a bunch of different input controls for a dashboard as a single visualization. I'd be interested to see how these are used/re-used because there's potential for each input control being it's own visualizations allowing us to utilize the existing Visualize workflow of selecting an index-pattern/etc. while allowing more re-use opportunities.
I'm in no way an authority on this design decision, but would be interested to hear others thoughts.
import InputRange from 'react-input-range'; | ||
import { FormRow } from './form_row'; | ||
|
||
export class RangeControl extends Component { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not finding the way the RangeControl works to be very intuitive. When it's first displayed and not being used for filtering, the start/end "dots" are on top of each other:
even though it's effective showing all values within the min-max and the following feels more natural:
Additionally, once the range slider has been moved from the starting position, it can't be put back there and stops at the first "step":
It's also impossible to move the Range slider to the max-value unless it's a multiple of the step:
The min-max labels are also occasionally cut-off for large values:
this.loadOptions = this.loadOptions.bind(this); | ||
} | ||
|
||
loadOptions(input, callback) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the IndexPatternSelect itself is loading the index-patterns, every-time that we add a new "input control" we're making another network request to retrieve the list of index patterns. Can we at least cache this for reuse so it only happens once?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of changing this to limit the index-pattern search to 100 results. Then I would configure Select.Async to fire the search every time a character is added to the filter. This is how the dashboard add 'Visualzation' and 'Saved Search' function. What do you think?
} | ||
|
||
async loadFields(indexPatternId) { | ||
if (!indexPatternId || indexPatternId.length === 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
loadFields is called by the constructor and whenever the indexPattern changes, potentially leading to a race condition if there's any type of inconsistent network latency.
@@ -0,0 +1,9 @@ | |||
export default function (kibana) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this should be split into two tabs, with only the "Update kibana filters on each change" being on the "Options" tab and everything else being on the first tab. Personally, I find "Update kibana filters on each change" being enabled by default to be a much more pleasant UX and wonder if this should be the default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great idea. I have split the editor into two tabs; Controls
and Options
The idea behind disabling "Update kibana filters on each change" by default is that only submitting all of the filters at a single instant puts the least amount of stress on the cluster. The default is designed for the usecase where the Panel contains many controls. Users can fiddle with several filters and then apply them all at once - so the dashboard only has to update 1 time instead of each time a control is modified.
@@ -0,0 +1,592 @@ | |||
// Jest Snapshot v1, https://goo.gl/fbAQLP | |||
|
|||
exports[`renders InputControlVisEditor 1`] = ` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way we're doing these snapshots feel like they're going to break all the time. They're testing the implementation details of all nested components, including the Kui framework, so anytime these change we'll have to update the snapshot. Have we considered using enzyme
to do shallow rendering for the snapshot tests?
@@ -0,0 +1,413 @@ | |||
// Jest Snapshot v1, https://goo.gl/fbAQLP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same concerns as above.
renderControls() { | ||
return this.props.controls.map((control, index) => { | ||
let controlComponent = null; | ||
switch (control.type) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a default
for this switch that throws an Error? This could lead to some hard to understand bugs.
if (status.params) { | ||
this.initControls(); | ||
} | ||
return new Promise(() => {}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we returning a Promise that never resolves? This is making the render-counter
attribute always stay at 0, which will cause issues with Reporting.
initControls() { | ||
this.controls = []; | ||
|
||
controlFactory( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking that if we change the controlFactory
to deal with a single control
, then we could switch from using a callback
below for each individual control and use a Promise
which seems more natural.
This would also allow us to use a Promise.all
for each of the controlFactory to use with the render
method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did it this way so that a single _msearch
would be used to init all controls in a panel. The weirdness comes from the fact that fetch.these
uses the defer promise pattern
@@ -112,6 +112,10 @@ dashboard-grid { | |||
i.remove { | |||
cursor: pointer; | |||
} | |||
|
|||
.gs-w { | |||
z-index: auto; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is something else setting this to something besides auto
? auto
should be the default z-index
for elements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gridster sets this to 1 for each grid. This caused problems with overflow of the list select and needed to be set to auto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Unfortunately I think we still need some refactoring with the You can use the I explained how to use this service, in the accessibility styleguide. |
@stacey-gammon I have added all of the requested jest tests and should have addressed all of your comments if you want to take another look. @timroes I have fixed all of the html elements with id collisions. |
this.state = { | ||
isEditorCollapsed: true | ||
}; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When just setting the initial state, the constructor isn't needed:
export class ControlEditor extends Component {
state = {
isEditorCollapsed: true
}
import { FieldSelect } from './field_select'; | ||
|
||
function filterField(field) { | ||
return ['number'].includes(field.type); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can be simplified to
return field.type === 'number'
@stacey-gammon @snide @kobelb What do you think about @JacobBrandt's idea of ditching |
@nreese to be completely honest, I don't find it to be intuitive at all... |
@nreese Now that I see it I can see what @kobelb is saying. Maybe try putting the two input fields side by side in the middle. <-------*----> 7105 to 8771 <---*--------> Another option is to keep react-input-range and put the input fields at the beginning or end of the slider <------*-------------------*--> 7105 to 8711 You'll still run into issues where the dots are on top of each other but with the input fields you'll at least be able to see the values you can't read on the slider. |
@snide Yea that's better if we're going to keep the one slider approach. |
I like the single slider better too. ++ to @snide's suggestion. |
@stacey-gammon Thanks for all the great feedback. Below are responses. I tried to summarize here instead of answering each individually. Would you mind taking another look at the PR?
|
@JacobBrandt I have updated the range control to include inputs for setting the value more precisely. Try it out and see if this makes sense |
@nreese Yep. This makes sense and will work well, thanks! |
@timroes Everything should be good to go. Can you take another look? |
* react editor example * ensure props are not updated * use new stageEditorParams method to stage parameter changes * make component stateless * use terms_vis_editor component * get add button to work * update vis controller to display terms input controls * update componenent when query bar updates * add functional test * lay ground work for different control types in single visulization * make editors for range and text controls * text control * implement type ahead suggestor for text control * add range slider * some CSS work * add submit button, move control init functionallity under control_factory * add custom options for control types * provide buttons to move controls up and down * Make ControlEditor component and clean up styling of editor * styling work * multi select for terms dropdown control * add option to disable filter staging, only enable submit button when filters are staged * clean up range styling * rename top level vis folder * cleanup * move control type select out of each control editor * dark theme styling * use ui/public/filter_manager/lib/phrases.js to build phrases filter, add tests to range filter manager * use savedObjectsClient to get index patterns * remove text control and add id to controls for react tracking * ensure fields get updated when index pattern changes * update PropTypes for react 15.6.1 * update to latest react-select to avoid isMounted deprecation warnings * fix input controls functional test * rename termsControl to listControl to be more generic * add function test for clear button, refactor directory structure * functional tests for updateFiltersOnChange is true * fix react-select clipping problem in dashboard * try clicking option instead of pressing enter to set react-select value in functional tests * react-select css * clean up control_editor component, make ListControlEditor component be function * add jest test for vis_editor component and accessibility * add decimal places option to range slider * add jest test for InputControlVis component * add default to switch blocks, split editor into seperate tabs, use shallow in snapshot tests * fix race condition in field_select, update index_pattern_select to fetch indexPatterns on each filter * clean up control initialization * use htmlIdGenerator to avoid html element id conflicts * update functional test to support new editor tabs * finish jest tests for sub componenets * mark vis as experimental, refactor buttons for better usability * fix bug in list control where unable to select options containing numbers and options containing commas. Truncate display of long list options * fix chart types functional test * fix jest tests, add margin to action buttons * remove binds from render functions * experement with native input range sliders * Revert "experement with native input range sliders" This reverts commit aed599e. * Use Promise.resolve in tests and replace _createRequest with searchSource.fetch * add inputs to range control
* react editor example * ensure props are not updated * use new stageEditorParams method to stage parameter changes * make component stateless * use terms_vis_editor component * get add button to work * update vis controller to display terms input controls * update componenent when query bar updates * add functional test * lay ground work for different control types in single visulization * make editors for range and text controls * text control * implement type ahead suggestor for text control * add range slider * some CSS work * add submit button, move control init functionallity under control_factory * add custom options for control types * provide buttons to move controls up and down * Make ControlEditor component and clean up styling of editor * styling work * multi select for terms dropdown control * add option to disable filter staging, only enable submit button when filters are staged * clean up range styling * rename top level vis folder * cleanup * move control type select out of each control editor * dark theme styling * use ui/public/filter_manager/lib/phrases.js to build phrases filter, add tests to range filter manager * use savedObjectsClient to get index patterns * remove text control and add id to controls for react tracking * ensure fields get updated when index pattern changes * update PropTypes for react 15.6.1 * update to latest react-select to avoid isMounted deprecation warnings * fix input controls functional test * rename termsControl to listControl to be more generic * add function test for clear button, refactor directory structure * functional tests for updateFiltersOnChange is true * fix react-select clipping problem in dashboard * try clicking option instead of pressing enter to set react-select value in functional tests * react-select css * clean up control_editor component, make ListControlEditor component be function * add jest test for vis_editor component and accessibility * add decimal places option to range slider * add jest test for InputControlVis component * add default to switch blocks, split editor into seperate tabs, use shallow in snapshot tests * fix race condition in field_select, update index_pattern_select to fetch indexPatterns on each filter * clean up control initialization * use htmlIdGenerator to avoid html element id conflicts * update functional test to support new editor tabs * finish jest tests for sub componenets * mark vis as experimental, refactor buttons for better usability * fix bug in list control where unable to select options containing numbers and options containing commas. Truncate display of long list options * fix chart types functional test * fix jest tests, add margin to action buttons * remove binds from render functions * experement with native input range sliders * Revert "experement with native input range sliders" This reverts commit aed599e. * Use Promise.resolve in tests and replace _createRequest with searchSource.fetch * add inputs to range control
backported to 6.x #14074 |
my2c., making this work on top of a saved search instead (or additionally to ) an index pattern could also be useful (Future version?) |
* react editor example * ensure props are not updated * use new stageEditorParams method to stage parameter changes * make component stateless * use terms_vis_editor component * get add button to work * update vis controller to display terms input controls * update componenent when query bar updates * add functional test * lay ground work for different control types in single visulization * make editors for range and text controls * text control * implement type ahead suggestor for text control * add range slider * some CSS work * add submit button, move control init functionallity under control_factory * add custom options for control types * provide buttons to move controls up and down * Make ControlEditor component and clean up styling of editor * styling work * multi select for terms dropdown control * add option to disable filter staging, only enable submit button when filters are staged * clean up range styling * rename top level vis folder * cleanup * move control type select out of each control editor * dark theme styling * use ui/public/filter_manager/lib/phrases.js to build phrases filter, add tests to range filter manager * use savedObjectsClient to get index patterns * remove text control and add id to controls for react tracking * ensure fields get updated when index pattern changes * update PropTypes for react 15.6.1 * update to latest react-select to avoid isMounted deprecation warnings * fix input controls functional test * rename termsControl to listControl to be more generic * add function test for clear button, refactor directory structure * functional tests for updateFiltersOnChange is true * fix react-select clipping problem in dashboard * try clicking option instead of pressing enter to set react-select value in functional tests * react-select css * clean up control_editor component, make ListControlEditor component be function * add jest test for vis_editor component and accessibility * add decimal places option to range slider * add jest test for InputControlVis component * add default to switch blocks, split editor into seperate tabs, use shallow in snapshot tests * fix race condition in field_select, update index_pattern_select to fetch indexPatterns on each filter * clean up control initialization * use htmlIdGenerator to avoid html element id conflicts * update functional test to support new editor tabs * finish jest tests for sub componenets * mark vis as experimental, refactor buttons for better usability * fix bug in list control where unable to select options containing numbers and options containing commas. Truncate display of long list options * fix chart types functional test * fix jest tests, add margin to action buttons * remove binds from render functions * experement with native input range sliders * Revert "experement with native input range sliders" This reverts commit aed599e. * Use Promise.resolve in tests and replace _createRequest with searchSource.fetch * add inputs to range control
* react editor example * ensure props are not updated * use new stageEditorParams method to stage parameter changes * make component stateless * use terms_vis_editor component * get add button to work * update vis controller to display terms input controls * update componenent when query bar updates * add functional test * lay ground work for different control types in single visulization * make editors for range and text controls * text control * implement type ahead suggestor for text control * add range slider * some CSS work * add submit button, move control init functionallity under control_factory * add custom options for control types * provide buttons to move controls up and down * Make ControlEditor component and clean up styling of editor * styling work * multi select for terms dropdown control * add option to disable filter staging, only enable submit button when filters are staged * clean up range styling * rename top level vis folder * cleanup * move control type select out of each control editor * dark theme styling * use ui/public/filter_manager/lib/phrases.js to build phrases filter, add tests to range filter manager * use savedObjectsClient to get index patterns * remove text control and add id to controls for react tracking * ensure fields get updated when index pattern changes * update PropTypes for react 15.6.1 * update to latest react-select to avoid isMounted deprecation warnings * fix input controls functional test * rename termsControl to listControl to be more generic * add function test for clear button, refactor directory structure * functional tests for updateFiltersOnChange is true * fix react-select clipping problem in dashboard * try clicking option instead of pressing enter to set react-select value in functional tests * react-select css * clean up control_editor component, make ListControlEditor component be function * add jest test for vis_editor component and accessibility * add decimal places option to range slider * add jest test for InputControlVis component * add default to switch blocks, split editor into seperate tabs, use shallow in snapshot tests * fix race condition in field_select, update index_pattern_select to fetch indexPatterns on each filter * clean up control initialization * use htmlIdGenerator to avoid html element id conflicts * update functional test to support new editor tabs * finish jest tests for sub componenets * mark vis as experimental, refactor buttons for better usability * fix bug in list control where unable to select options containing numbers and options containing commas. Truncate display of long list options * fix chart types functional test * fix jest tests, add margin to action buttons * remove binds from render functions * experement with native input range sliders * Revert "experement with native input range sliders" This reverts commit aed599e. * Use Promise.resolve in tests and replace _createRequest with searchSource.fetch * add inputs to range control
There should be an option to enable drop down fields depending on each other. When you choose a value in the first field there should only be those values showed up in the second that are existing in the index in combination with the first value. And vice versa. |
Adds visualization type for creating input panels for dashboards.
Range slider
input. Slider min and max obtained via a min/max aggregation call when panel is first rendered.Options list
input. Options are loaded via a terms aggregation call when panel is first rendered.Replaces experimental PRs #11873 and #12126