[App Search] Added the Documents View

[JasonStoltz]

Summary

This PR adds a Documents View for the App Search Plugin, accessible via the 'Documents' link in the Engines sub nav.

The view is ported from our stand-alone UI. Most notable about this view is that it uses the https://github.com/elastic/search-ui library.

It looks like it balloons the size of the enterpriseSearch async chunk to ~1.3MB, increasing by ~630.3KB (based on the build report below). I'm guessing this is due to all of the transitive dependencies brought in by @elastic/react-search-ui. Is there a way to see a breakdown of the chunk?

We don't use the majority of the transitive dependencies that are brought in. I thought these might get shaken out by tree shaking, but perhaps not. We might be able to do some work on search-ui to omit these dependencies.

Given that, I'm looking for thoughts and opinions on how to proceed. The commit that adds Search UI is here: 9b3a7a6. CC specifically @spalger and @constancecchen.

The view is completely functional, but I do leave a few things out to be implemented later as separate PRs:

What it includes:

• Added @elastic/react-search-ui and @elastic/search-ui-app-search-connector as dependencies.
• Added the search-ui-based search experience to the Documents page.

What it does not include the following, which will be implemented in separate PRs:

• This PR does not include the correct "Result" view, which must requires the StuiResult component to be migrated. This uses a temporary view for showing results.
• This PR does not include the facets and the ability to configure those facets.
• This PR does not include polling to detect when indexing finishes on an Engine.
• This PR does not have the Index Documents button wired up.

QA

You can see various forms of "No Results" messages in this PR by using the following scenarios:

• Perform a search that returns no results on the Documents page
• Visit the Documents page on a regular engine that has no Documents indexed
• Visit the Document page on a meta engine that has no Documents indexed

Another scenario to note:

• When visiting this page for a meta engine, there should be a blue banner displayed at the top

Reviewing this PR

⚠️ I recommend stepping through this commit by commit. ⚠️

It is a big PR, but the atomic commits should make this easier to review in logical chunks.

Note that the majority of the new code is more or less copy / paste from the old code repository. The changes I made were mostly limited to adding i18n, fixing axe failures, and writing tests. I made little to no intentional refactors.

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
• Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[cee-chen]

It looks like it balloons the size of the enterpriseSearch async chunk to ~1.3MB, increasing by ~630.3KB (based on the build report below).

1.3MB doesn't feel too bad considering it's async, and we can potentially use React.lazy to load in the Documents view so it only loads on that view and not every single view (correct me if I'm wrong Spencer).

I'm guessing this is due to all of the transitive dependencies brought in by @elastic/react-search-ui. Is there a way to see a breakdown of the chunk?

Not sure if this is what you mean, but Josh Dover has a Kibana dashboard comparing various plugin sizes that might be helpful? For Search UI, I think there are dependency breakdown tools that @yakhinvadim has used in the past - any chance you could run one of those on Search UI, Vadim?

We don't use the majority of the transitive dependencies that are brought in. I thought these might get shaken out by tree shaking, but perhaps not. We might be able to do some work on search-ui to omit these dependencies.

My very limited experience w/ tree shaking is that it never works how you expect haha. Just want to level-set here as well Spencer, we're definitely happy to re-look at Search UI but our current top/pressing priority is merging App Search fully to Kibana by 7.13 - it would be awesome if Search UI could be added as-is currently and improved post-MVP, but if you see anything that would be a blocker, please let us know!

[yakhinvadim]

@constancecchen would this be enough? https://bundlephobia.com/result?p=@elastic/react-search-ui@1.5.0

[JasonStoltz]

@yakhinvadim Nice Vadim, that is helpful. Interestingly, it looks like that says the bundle size is 262.2
kb. I suppose maybe the the other 300+ kb is just our new code. There are quite a few lines in this PR.

To note, if I were able to publish a version of react-search-ui that dropped it's dependency on https://bundlephobia.com/result?p=@elastic/react-search-ui-views@1.5.0, we'd presumably be able to reduce the bundle size by 187kb.

I'm guessing that's not significant enough to be a show stopper for this PR.

[cee-chen]

First small set of comments, nothing blocking / mostly very minor - trying to batch my comments and review this PR in bits at a time

[cee-chen]

Second batch of comments/q's

[cee-chen]

3rd batch of comments - only 1 set / 6 more files to go!

[JasonStoltz]

@constancecchen Ready for a second look, all of those commits correspond with a comment you made. There are a couple of additional commits at the end:

a2d9ed8 - reset yarn.lock - I had to regenerate yarn.lock to resolve a merge error
a2d9ed8 - fix type errors - Fixed error I introduced in previous commits

[cee-chen]

Changes look great! One non-blocking comment, approving in advance for when i18n error is fixed

[JasonStoltz]

Thanks @constancecchen 👍 👍 👍

[cee-chen]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: ce30ab1

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
enterpriseSearch	636	969	+333

Async chunks

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

id	before	after	diff
enterpriseSearch	1.1MB	1.7MB	⚠️ +631.0KB

Distributable file count

id	before	after	diff
default	43496	46520	+3024
oss	22757	27561	+4804

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
upgradeAssistant	60.4KB	60.5KB	+87.0B

History

• 💔 Build #91878 failed 6a3a91c
• 💔 Build #91841 failed a2c9d1c
• 💔 Build #91791 failed 3aba726
• 💔 Build #91767 failed 59f001d
• 💔 Build #91523 failed 724bb27

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[kibanamachine]

Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync.