Conditionally show Visualize button based on aggregatable status

[Bargs]

Now that we know which fields are aggregatable, we should only show the Visualize button in the Discover sidebar when a field is in fact aggregatable.

Fixes #5873

[cjcenizal]

Two points of note...

1. Kibana 5.0 seems to show a different error than what's show in the linked issue:

I don't really know what this error means. How does it relate to the idea of a field being aggregatable?

2. This tooltip would previously be visible on buttons like this:

How does this warning relate to the idea of a field being aggregatable, if at all?

[cjcenizal]

I think this would be more ergonomic if it called a method, like this:

ng-if="isFieldVisualizable(field)"

which then called a service:

import isFieldVisualizable from 'ui/visualize/is_field_visualizable'; // location tbd
scope.isFieldVisualizable = isFieldVisualizable;

which codified this rule (and future related rules):

// is_field_visualizable.js
export default isFieldVisualizable(field) {
  // Some explanation here about why non-aggregatable fields can't be visualized.
  if (!field.aggregatable) {
    return false;
  }

  return true;
}

It seems like a lot of code for such a small feature, but I think it's important we codify our business logic this way. Otherwise the "what" of the code isn't justified by a "why". Other benefits include increased readability, testability (we can test the service), and scalability (we can add additional rules to the service).

[Bargs]

I would agree if there were multiple factors that went into deciding if a field was "visualizable", but as things stand today I think that's a premature abstraction. Non-aggregatable fields can't be visualized because Kibana visualizes aggregations. I could add an inline comment which I think would be less confusing than creating a new service.

[cjcenizal]

That makes sense. How about a compromise? Can you just put the isFieldVisualizable method on the scope instead of in a separate service? At least this way the code becomes self-documenting.

[Bargs]

I added an additional flag to the field object itself, I think it's a more appropriate place to put that kind of logic. Let me know how that looks to you.

[cjcenizal]

The code works great! I just had a couple questions for my own enlightenment, and a couple small suggestions.

[tbragin]

I checked out the PR and I see the following behavior - when you repeatedly open and close a field where the visualize button is shown, it remains visible when you close the field, and thus when you open it again, now you see multiple buttons. Anyone else sees that behavior?

[Bargs]

I don't really know what this error means. How does it relate to the idea of a field being aggregatable?

Analyzed fields can only be aggregated if they have fielddata enabled. Pre-5.0 it was enabled by default, now it's disabled by default so that these errors are much more common.

How does this warning relate to the idea of a field being aggregatable, if at all?

If a user manually enables fielddata on an analyzed field they can still create visualizations with it, but it'll probably suck up a lot of memory and give unexpected results because you're visualizing the analyzed data, not the data as it originally existed in _source. So this warning is still relevant in those cases.

[Bargs]

@tbragin yup I see that too, and confirmed it only happens in this PR. Great catch

[Bargs]

@tbragin fixed the whack-a-button problem. Ready for another look.

[cjcenizal]

LGTM

[jbudz]

whoops, that's a small gif. I'm clicking on xss, which doesn't have visualize (expected), but clicking visualize on the field above tries to load xss still.

[Bargs]

@jbudz weird. That appears to be an existing issue in master as well. I'll see if I can fix it though.

[jbudz]

If you want a separate issue for it, this LGTM