Skip to content
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

[indexPatterns/create] disable time-based options when needed #12011

Merged

Conversation

spalger
Copy link
Contributor

@spalger spalger commented May 25, 2017

When the time field option "I don't want to use the time filter" is chosen the options for wildcard expanding and time-based patterns are not hidden. This fixes that by adding a controller.canUseTimePattern() method that is used in the view to remove the irrelevant sections when necessary.

@spalger spalger force-pushed the index-patterns/disable-time-based-opts branch from 598be43 to 800b112 Compare May 26, 2017 00:26
@spalger spalger added review and removed blocked labels May 26, 2017
Copy link
Contributor

@chrisronline chrisronline left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I had a few questions and one small request

// if timeFieldOption has a fieldName it's a time field, otherwise
// it's a way to opt-out of the time field or an indication that there
// are no fields available
return !!this.formValues.timeFieldOption.fieldName;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've seen Boolean( used in other places. Are we trying to standardize on one or the other?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either works for me, I don't think we have picked one.

return (
this.isTimeBased() &&
!this.formValues.nameIsPattern &&
_.includes(this.formValues.name, '*')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of scope for this PR, but isn't this.formValues.name a string? If it's a string, we probably don't need to use the lodash .includes( method which is normally used on collections.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, I imagine it's used here to automatically handle the scenario when formValues.name is not a string (null/undefined for instance)

? true
: undefined;

// Only event-time-based index patterns set an intervalName.
const intervalName = (nameIsPattern && nameInterval)
const intervalName = (this.canUseTimePattern() && nameIsPattern && nameInterval)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the select field that sets the nameInterval is now hidden behind a more aggressive ng-if, do you think we only need to check if nameInterval exists at this point? It feels the first two conditions are redundant

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, ng-if doesn't unset the model value when the inputs are removed from the view, so it's possible that the name interval is still set when the name isn't actually a time pattern

@@ -320,24 +338,28 @@ uiModules.get('apps/management')

let lastPromise;
resetIndex();
samplePromise = lastPromise = updateSamples()
samplePromise = lastPromise = Promise.resolve()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole samplePromise and lastPromise is very confusing. While you're in here, do you mind adding some clarifying comments explaining what these do and why they are necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to, do you think it would help it I made it look more like this? https://github.com/elastic/kibana/pull/12007/files#diff-f5a949c353fd77eda951919524c3b7ecR199

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be clearer if we use the pattern you linked to. I find this:

samplePromise = lastPromise = Promise.resolve()

to be a real head scratcher.

Copy link
Contributor

@cjcenizal cjcenizal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this looks great, I just think the async-request-tracking logic would be clarified.

@@ -160,7 +160,7 @@
</div>

<!-- Use event times checkbox -->
<div class="kuiVerticalRhythm">
<div class="kuiVerticalRhythm" ng-if="controller.canUseTimePattern()">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe put onto multiple lines for a consistent pattern?

<div
  class="kuiVerticalRhythm"
  ng-if="controller.canUseTimePattern()"
>

@@ -282,7 +300,7 @@ uiModules.get('apps/management')

$scope.$watchMulti([
'controller.formValues.nameIsPattern',
'controller.formValues.nameInterval.name'
'controller.formValues.nameInterval.name',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some people would shake their heads and tsk at these types of "unrelated" changes, but I applaud you, sir.

@@ -320,24 +338,28 @@ uiModules.get('apps/management')

let lastPromise;
resetIndex();
samplePromise = lastPromise = updateSamples()
samplePromise = lastPromise = Promise.resolve()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be clearer if we use the pattern you linked to. I find this:

samplePromise = lastPromise = Promise.resolve()

to be a real head scratcher.

@spalger
Copy link
Contributor Author

spalger commented May 26, 2017

@cjcenizal @chrisronline thanks for taking a look, hope I've covered everything

Copy link
Contributor

@cjcenizal cjcenizal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@chrisronline
Copy link
Contributor

LGTM!

@spalger spalger merged commit 185912d into elastic:master May 30, 2017
spalger added a commit that referenced this pull request May 30, 2017
* [indexPatterns/create] disable time-based options when needed

* !! -> Boolean()

* [indexPatterns/create] refactor sample deduping for clarity

* [indexPattern/create] wrap html attributes

(cherry picked from commit 185912d)
@spalger
Copy link
Contributor Author

spalger commented May 30, 2017

5.5/5.x: 15d4d83

@spalger spalger deleted the index-patterns/disable-time-based-opts branch May 30, 2017 18:40
snide pushed a commit to snide/kibana that referenced this pull request May 30, 2017
…c#12011)

* [indexPatterns/create] disable time-based options when needed

* !! -> Boolean()

* [indexPatterns/create] refactor sample deduping for clarity

* [indexPattern/create] wrap html attributes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants