Use index patterns service inside data plugin (rather than importing from ui/public)

[lizozom]

Summary

Use index patterns service inside data plugin (rather than importing from ui/public)

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-app-arch

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[lukeelmers]

Another way you could do this would be importing from the top level (../../public) as mentioned in the IndexPatterns TS PR. That way we use the same "official" contracts between services that any other plugins would use:

// i want to import static code from another service within the data plugin
import { IndexPattern } from '../../../public';

// i want to use runtime dependencies from another service within the data plugin
class DataPlugin {
  setup(core, deps) {
    const indexPatterns = this.indexPatterns.setup();
    return {
      indexPatterns,
      myService: this.myService.setup({ indexPatterns })
    };
  }
}
MyService.setup({ indexPatterns });

// i want to use an internal method from another service & it is not publicly exposed from `data`
import { InternalThing } from '../../index_patterns';
// ^ makes it clear when we are relying on something internal to the data plugin

[lizozom]

@lukeelmers I'm not sure how I feel about the static code import style, in a comlpex plugin like data.

Take this line for example:

https://github.com/elastic/kibana/pull/41639/files#diff-56d9e9ed6bea5cc4e4d3b79cddac2684R38

import { Field, IndexPattern } from '../../../index_patterns';

If we go with this approach, this line will become:

import { Field, IndexPattern } from '../../../';

1. We're losing the ability to find which service the import comes from
2. If we're importing things from multiple services, we're going to mix them in one long import.

What do you think?

[lukeelmers]

I agree '../../../' is far more confusing, so in that case I'd go up another level to include the public directory: '../../../../public'. I don't feel strongly about this, was just bringing it up as an idea here.

I think this illustrates a larger decision we need to make which is how we organize our static exports by service to make them easier for devs to consume. That way you don't lose the context of which service you are dealing with when importing from public/index.

But for now, I think your approach importing from services ../../index_pattern works great and will be the better solution. It's all internal to our plugin anyway, so if we change our minds later we will have the flexibility to do this however we want.