[index patterns] Index pattern creation modal API

[mattkime]

Some new text

Parent issue for index pattern creation modal - [https://github.com//issues/84725|https://github.com//issues/84725]

A new IndexPatternEditor plugin will be created which will expose an interface for an index pattern creation flyout. It will be loaded asynchronously to be mindful of bundle size. It will initially be used by Index Pattern Management.

Note - this API is heavily based on the IndexPatternFieldEditor API - [https://github.com/elastic/kibana/tree/master/src/plugins/index_pattern_field_editor|https://github.com/elastic/kibana/tree/master/src/plugins/index_pattern_field_editor].

const MyComponent = () => \{
// Access the plugin through context
const \{ indexPatternEditor } = useAppPlugins();

// Ref of the handler to close the editor
const closeIndexPatternEditor = useRef(() => \{});

const saveIndexPattern = (indexPattern: IndexPattern) => \{
// Respond to new index pattern
};

const openIndexPatternEditor = async() => \{
// Lazy load the editor
const \{ openEditor } = await indexPatternEditor.loadEditor();

closeIndexPatternEditor.current = openEditor(\{
defaults?: \{
title?: string;
timestampField?: string;
isRollup?: boolean;
},
config?: \{
requireTimestampField?: boolean;
},
onSave: saveIndexPattern
});
};

useEffect(() => \{
return () => \{
// Remove the editor when the component unmounts
closeIndexPatternEditor?.current();
};
}, \[]);

return (
<button onClick=\{openIndexPatternEditor}>Add index pattern</button>
)
}

A convenience function will also be provided for checking permissions -

const canCreateIndexPattern = indexPatternEditor.userPermissions.editIndexPattern();

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[mattkime]

In particular, I'd like feedback from @weltenwort @flash1293 @timroes

[streamich]

I believe we are doing flyouts not in the best way in many places in Kibana. In particular, it would be great to open flyouts in declerative way, same as it is provided by EUI library. For example:

const MyComponent = () => {
 const { indexPatternEditor } = useAppPlugins();
 const [open, setOpen] = React.useState(false);
 
 return (
   <>
     <button onClick={() => setOpen(true)}>Add index pattern</button>
     {open && <indexPatternEditor.Flyout onSave={() => {}} />}
   </>
 )
}

It would be great to implement the <indexPatternEditor.Flyout> component as the basis. And then if some app still needs to open the flyout in an imperative way, construction on top of it can be created by index patterns or the app itself to open the flyout in an imperative way. Maybe it is even better to leave that up to the app, to encourage good patterns.

[flash1293]

I think an imperative API should be provided because it's also usable outside of React which can sometimes become necessary (e.g. inside of an action handler). While it's possible to use the react api in this situation as well, it's cumbersome and IMHO we shouldn't push this to the consumer. If we feel strongly about the "manual" flyout reference management (I agree it can lead to unclosed flyouts leaking out of the app which is also not great), I would vote for providing two APIs (imperative and declarative). This is also consistent what we are doing for the field deletion modal:

kibana/src/plugins/index_pattern_field_editor/public/plugin.ts

Line 56 in 68ed17a

DeleteRuntimeFieldProvider: getDeleteFieldProvider(openDeleteModal),

Besides that I'm pretty happy with this API. Didn't discuss this with design or anything, but we could add a pre-set for the index pattern name to the context:

openEditor({
  onSave,
  initalPatternString,
});

This could be used for a user flow like this:

• User is opening the index pattern chooser in Lens and starts searching for a pattern
• Notices there's no index pattern for this name yet
• There's an option in the chooser "create this index pattern" (which will open the editor with the string the user typed so far)

[streamich]

If you go for imperative approach maybe worth creating a helper, say useIndexPatternFlyout, so every user of the flyout does not need to write the boilerplate code:

const MyComponent = () => {
 const { indexPatternEditor } = useAppPlugins();
 const { open } = useIndexPatternFlyout(indexPatternEditor, {
   onSave: () => {},
 });
 
 return (
   <button onClick={open}>Add index pattern</button>
 )
}

[mattkime]

As best I can tell, we have specific use cases that need the imperative API. Do we have specific use cases that need the declarative api? Otherwise I'm tempted to stick with imperative until its unsuitable for a given situation. What do you think @streamich @flash1293 ?

[mattkime]

Besides that I'm pretty happy with this API. Didn't discuss this with design or anything, but we could add a pre-set for the index pattern name to the context:

@flash1293

Yes, this could be added easily. We can add it when its needed.

[weltenwort]

Thanks for working on this, @mattkime! The ability to prepopulate an index pattern name would be pretty useful to provide guidance to the user. Similarly, it would be useful to require the timestamp field because many observability use-cases depend on such a field. Would that be possible?

[mattkime]

@weltenwort I updated the code example with some type interfaces. Let me know what you think.

[weltenwort]

That looks like it should cover the requirements I can anticipate. 👍

💭 On a side-note, I wonder if you perceive the requireTimestampField as being too specific? Alternatively the consumer could pass a generic validation function? Just thinking loudly. 🤷

[flash1293]

Alternatively the consumer could pass a generic validation function

My 2 cents - a generic validation function is more flexible, but the UX is definitely worse because the creation dialog can't prevent the problem from happening (e.g. by simply omitting "No default time field" option in the dropdown) nor highlight the problematic field in the form.

[weltenwort]

[...] the UX is definitely worse because the creation dialog can't prevent the problem from happening (e.g. by simply omitting "No default time field" option in the dropdown) nor highlight the problematic field in the form.

Very good point, thank you!

[mattkime]

implemented by #84725