Support ability to create a visualization without an existing index pattern object

[stacey-gammon]

I think this fits into the "Time to visualize" efforts (#51318)

It's been talked about before but I couldn't find an issue. This would allow users to skip the step of creating an index pattern object before creating a visualization. Something like:

This ties into the generic data source concept as well, since it'd probably be nice to allow the user to type in/edit EQL inside Lens rather than navigate to "index patterns" (or if we renamed it "data sources") .

[elasticmachine]

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

[wylieconlon]

The title of this issue is definitely the goal, but it isn't very clear to me how we would get there. Visualizations depend heavily on the index pattern service.

[stacey-gammon]

I was thinking about in the context of #55842

Either feature I understand would be a huge effort and the priority of either one inside of Lens is up in the air atm.

[wylieconlon]

Okay, if this is Lens-specific then there is actually a datasource selector that is going to be present at a higher level than the index pattern selector. What you are seeing is rendered within the Index Pattern data source.

[timroes]

I marked this as blocked, since most of this would depend on having better index pattern APIs that allow us to use "ad hoc" index patterns.

[stacey-gammon]

Blocked on: #69379 and #61769

[mattkime]

Ad hoc index patterns have been available for some time but the interface has been so indirect as to make it unclear. Part of the refactoring work is to make save functionality explicit.

I think most of the work will be in the visualization, determining whether an index pattern reference is ad hoc or not.

[mattkime]

Need to write a better summary but this PR has the bulk of the index pattern refactor. #77791

Example -

const adHocPattern = await IndexPatterns.create({ title: 'kibana', timeFieldName: '@timestamp'});

[stacey-gammon]

Closing in favor of #67711.