[DataView] show empty matching sources when no matched index pattern

[lsq645599166]

Summary

Closes #194736

Show empty matching sources when no matched index pattern in create data view panel

Before

After

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[kertal]

/ci

[kertal]

Thx so much for this contribution 👍
To move bring this over the finishing line, there's one mandatory change:
The one Jest test failure needs to be fixed

One optional change you could try is automatically show "All sources" for the given case, because matching sources is giving no useful information anyway. But this is not mandatory, just wanted to share some thoughts

We definitely appreciate you contribution

[lsq645599166]

Thx so much for this contribution 👍 To move bring this over the finishing line, there's one mandatory change: The one Jest test failure needs to be fixed

One optional change you could try is automatically show "All sources" for the given case, because matching sources is giving no useful information anyway. But this is not mandatory, just wanted to share some thoughts

We definitely appreciate you contribution

Thanks for you suggestion，I‘ll try to optimize the UX in the later commit

[lsq645599166]

@kertal I have already optimize the UX and fix the unit test, could you please rerun the CI.

[lsq645599166]

@elasticmachine merge upstream

[kertal]

sure, thx!

[kertal]

/ci

[kertal]

@elasticmachine merge upstream

[kertal]

Sorry that it took so long @lsq645599166 ... So those test are fixed, this is great. I was testing your latest addtion and was thinking what if we could change it so the state we aim to approve is displayed this way, no tabs are being displayed, just the list

Wdyt @jughosta , I see you have been working on this part of the code a while ago

For me it seems the following changes would enable this, and we would need no useEffect here

 let currentlyVisibleIndices;
  let currentViewMode;

  if (
    (title.length &&
      matched.visibleIndices.length &&
      !isAboutToIncludeMoreIndices(title) &&
      viewMode !== ViewMode.allIndices) ||
    viewMode === ViewMode.onlyMatchingIndices
  ) {
    currentlyVisibleIndices = matched.visibleIndices;
    currentViewMode = ViewMode.onlyMatchingIndices;
  } else {
    currentlyVisibleIndices = matched.allIndices;
    currentViewMode = ViewMode.allIndices;
  }

and

 {Boolean(title) && Boolean(matched.visibleIndices.length) && (

wdyt @jughosta? 🙏

[jughosta]

Sorry, don't have time to look into it now. To me it would be better to avoid too many UI changes when a user is typing a value. Otherwise it would be distracting. I rather keep the tabs.

[kertal]

To me it would be better to avoid too many UI changes when a user is typing a value. Otherwise it would be distracting. I rather keep the tabs.

thx @jughosta , I've tested it and you're right abot the too many UI changes. Let's focus on the problem we solve here and keep the behavior, not changing the user selection with a useEffect. So pls, @lsq645599166 can you remove the useEffect logic? Many thx!

[davismcphee]

++ to avoiding messing with the tabs. I see how it could be helpful to auto switch tabs, but if the user makes a typo which causes it to switch, then backspaces to fix the typo, they'd now be on the "All sources" tab and have to manually switch back (trying to auto switch back again would likely be tricky and error prone). At most I'd add a "No matching sources found" message to the "Matching sources" tab to avoid an empty display (even this may not be necessary with the existing callout though, would just help reinforce and fill the empty space).

[lsq645599166]

++ to avoiding messing with the tabs. I see how it could be helpful to auto switch tabs, but if the user makes a typo which causes it to switch, then backspaces to fix the typo, they'd now be on the "All sources" tab and have to manually switch back (trying to auto switch back again would likely be tricky and error prone). At most I'd add a "No matching sources found" message to the "Matching sources" tab to avoid an empty display (even this may not be necessary with the existing callout though, would just help reinforce and fill the empty space).

Thanks for suggestion, I've added a message when no matched index, reuse the i18n key indexPatternEditor.status.notMatchLabel.notMatchNoIndicesDetail

[lsq645599166]

@elasticmachine merge upstream

[kertal]

/ci

[davismcphee]

Thanks again for the contribution @lsq645599166, and apologies for all the back and forth on this. After testing this locally, I think misunderstood the intent of the code originally. I also overlooked @kertal's second comment where he suggested hiding the tabs entirely, but I agree this is actually the best approach.

We already do this before the user has typed anything, and we show the full list of sources:

We also intentionally return the full list as visibleIndices from getMatchedIndices when there are no matches because we want the user to see the available options when their pattern doesn't match. It turns out this was behaving as intended, but the confusing part was that the tabs were still visible and "Matching sources" was still selected.

If we hide the tabs when there are no matches as @kertal suggested, it behaves the same as if the user hadn't typed anything, so there's no confusion about the tabs, and they'll still be able to see the available sources:

This seems like the least confusing and most consistent behaviour (and matches the original intent). Luckily if we follow the same logic used in src/plugins/data_view_editor/public/components/preview_panel/status_message/status_message.tsx, I think we should be able to revert all changes except for this line in PreviewPanel.

Suggested change

	{Boolean(title) && (
	{title.length > 0 && (matched.exactMatchedIndices.length > 0 || matched.partialMatchedIndices.length > 0) && (

[lsq645599166]

Ok, I commit a change to hide tab when no matched index.

[lsq645599166]

@elasticmachine merge upstream

[davismcphee]

/ci

[lsq645599166]

@kertal @davismcphee What should I do next

[davismcphee]

Hey @lsq645599166, it looks like there are still changes to getMatchedIndices. Unless I'm overlooking something, I think we should be good to revert all the changes and just handle this in the conditional for the EuiButtonGroup, as mentioned in my last comment.

[lsq645599166]

Hey @lsq645599166, it looks like there are still changes to getMatchedIndices. Unless I'm overlooking something, I think we should be good to revert all the changes and just handle this in the conditional for the EuiButtonGroup, as mentioned in my last comment.

Sorry, I misunderstand the meaning of your last comment. I revert getMatchedIndices in the latest commit.

[lsq645599166]

@elasticmachine merge upstream

[davismcphee]

/ci

[davismcphee]

/ci

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: fb3add3

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
dataViewEditor	49.3KB	49.4KB	+56.0B

History

• 💔 Build #245281 failed 0b27ea4
• 💚 Build #244102 succeeded a157db9
• 💚 Build #242022 succeeded 010d44b
• 💔 Build #241090 failed 1d447d2

cc @lsq645599166

[davismcphee]

@elasticmachine run docs-build

[davismcphee]

With the latest changes it LGTM! Thanks for working on this 👍

[kibanamachine]

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/11491907929

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation