Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[App Search] Add a Result Component #85046

Merged
merged 26 commits into from
Dec 11, 2020

Conversation

JasonStoltz
Copy link
Member

Summary

This PR adds a reusable Result component, which will ultimately be leveraged in a number of locations in the UI including; Documents, Curations, Query Tester, and Relevance Tuning.

result

This was migrated from the StuiResult component in ent-search.

This PR primarily focuses on the Documents view, and migrating ONLY what is required by the Documents view. (There is only one exception to this, and that is the inclusion of the "score" in the ResultHeader component, which won't be used for the Documents view).

screencapture-localhost-5601-app-enterprise-search-app-search-engines-states-documents-2020-12-04-12_28_04

Things that were not migrated over that we will need to migrate in follow up PRs for the Documents view, but were left out to keep this PR small:

  • Field type and snippet highlighting, which will require us to fetch the engine schema.
  • Linking to a detail page.

Things that were not migrated over that we will need to migrate later for other views:

  • The condensed option, which appears to be used in Query Tester, Curations, and Relevance Tuning
  • Support for showing boosts, which will show which fields have been boosted and will be used on Relevance Tuning
  • Support for searchFields, which will show which fields have weights applied and will be used on Relevance Tuning
  • extra action support, which lets us add an additional option to the right side of the Result element, and will be used on Curations
  • unsearched fields support, which will show unsearched fields, like 'number' and 'date' field types below other fields. This may be required on the Relevance Tuning page.

Things that were intentionally not migrated, and won't be migrated:

  • Click tracking on the result component, when clicking into the Document Details page. It was decided that we will no longer track Dashboard actions in Analytics with the migration to Kibana.
  • Many styles - this PR tried to pull in only the minimum number of styles required.
  • A tool tip that used to show when hovering over truncated Engine names and IDs in the Result Header. We instead rely on the title attribute for simplicity.
  • unsearched fields support on the Documents view, as we decided that showing which fields are not searched is confusing to see on the Documents page

The Library Page

This component has many permutations, and it's very difficult to develop a component like this without visually seeing all of the permutations in a single place. Something like a styleguide or storybook is often used for this. In lieu of a full blown styleguide, I added a simple /library page to App Search, accessible in dev mode only, which shows all of the variations of this component.

We DO NOT need to keep it if this is a bad idea. This was a helpful development aid, and will be helpful in the future as we start to add more states to this component. That being said, we don't need to keep it, and I can easily delete it at this point.

screencapture-localhost-5601-app-enterprise-search-app-search-library-2020-12-04-12_12_12

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@JasonStoltz JasonStoltz added release_note:skip Skip the PR/issue when compiling release notes v7.11.0 labels Dec 4, 2020
@JasonStoltz JasonStoltz requested review from a team December 4, 2020 17:30
Copy link
Contributor

@cee-chen cee-chen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First pass of comments - mostly a quick look at types & some SCSS, will dig more deeply in later!

@JasonStoltz JasonStoltz requested a review from cee-chen December 7, 2020 17:00
@JasonStoltz
Copy link
Member Author

@constancecchen Ready for a second look

@JasonStoltz JasonStoltz requested a review from cee-chen December 7, 2020 19:37
Copy link
Contributor

@cee-chen cee-chen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies that my comments are coming in so piecemeal - I'm super scattered/not very focused today so I figured I'd just try to give you stuff to work on as I go instead of a huge dump at the end of the day.

Just assume I'm still slowly working my way through QA/files until I make a comment saying "final set of comments" or something similar 😅

- remove display grid on contentWrap
- remove grid on contentInner
- remove unnecessary fieldsetContainer wrapper
- remove extra blank div
- remove unnecessary CSS on .appSearchResult
…naming

(apologies for going back and forth on this)
Copy link
Contributor

@cee-chen cee-chen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment set contains:

  • Some misc naming simplification suggestions, now that we've removed some extra wrappers
  • Some semantic markup suggestions

Full diff can be checked here for ease: cee-chen@dda58c4

Copy link
Contributor

@cee-chen cee-chen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Misc comment set: Couple of unnecessary key props, extra span, an accessibility suggestion

Copy link
Contributor

@cee-chen cee-chen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After doing some responsive testing at 320px device width, I'd like to propose a change/simplification to the ResultField CSS file that should look better on mobile and look mostly similar on larger views:

Mobile 320px

Before (left), After (right)
before_small after_small

Notice that the after has much more readable content

Standard / 700px (should not have much change)

Before (top), After (bottom)
before_large
after_large

@cee-chen
Copy link
Contributor

cee-chen commented Dec 8, 2020

I have another set of proposed mobile responsive changes for ResultHeader here - unfortunately it's tougher to add code line comments/suggestions for those since they rely on changes not yet made / in my above comments. So instead, here's the diff:

cee-chen@a2573bd#diff-3e0fecf720a0b1119904329cd03c897a75961a7a9959e79881cb9ff08c7ee43b

And here's screencaps of the visual changes:

Before

After

Just IMO, the after is a little more organized/tidier and also better handles long overflowing IDs - lmk what you think!

@cee-chen
Copy link
Contributor

cee-chen commented Dec 8, 2020

OK, sorry, I know that was a lot :) That was my final set of DOM/CSS comments (mostly from inspecting the browser & doing testing) - I haven't yet reviewed any JS logic as a heads up, I'll probably have to do that tomorrow.

I have all (I think) of the above changes in code diffs if you'd prefer to cherry-pick them for speed - no worries if not and you'd rather review each comment individually: JasonStoltz/kibana@documents-view-4...constancecchen:documents-view-4

@JasonStoltz
Copy link
Member Author

Looks great @constancecchen! Really handy that you put this into a branch, it made it easy to apply your changes. This clean this up quite a bit, thank you! 👍 👍

@JasonStoltz JasonStoltz requested a review from cee-chen December 8, 2020 18:34
@JasonStoltz
Copy link
Member Author

I think your branch had everything, I don't think I missed any of your comments.

Copy link
Contributor

@cee-chen cee-chen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few small nit comments (that I missed in previous passes, totally on me) and one perf suggestion - everything looks amazing and this is my actual last set of comments! 🙇‍♀️

expect(wrapper.find('[data-test-subj="ResultEngine"]').prop('value')).toBe('my-engine');
});

it('does not render an engine name if the ids match, which means it is not a meta engine', () => {
Copy link
Contributor

@cee-chen cee-chen Dec 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[not a change request, just me thinking out loud] I wonder if it would it be potentially possible to pass an isMetaEngine var directly to the Result view, so that we don't have to make a manual check per-result ourselves? We have isMetaEngine is EngineLogic, just not sure if it applies to the Result view

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are right, that would definitely have worked.

@JasonStoltz JasonStoltz requested a review from cee-chen December 9, 2020 18:22
@cee-chen
Copy link
Contributor

cee-chen commented Dec 9, 2020

@elasticmachine merge upstream

Copy link
Contributor

@cee-chen cee-chen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks so much as always for your patience and awesome work Jason! I can't say enough how excited I am for this super clean Result view and the awesome library/storybook pattern to potentially reuse for the future!

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
enterpriseSearch 969 1011 +42

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.7MB 1.7MB +32.2KB

Distributable file count

id before after diff
default 46984 47748 +764

History

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

@JasonStoltz JasonStoltz merged commit 31a1cc0 into elastic:master Dec 11, 2020
@JasonStoltz JasonStoltz deleted the documents-view-4 branch December 11, 2020 19:00
JasonStoltz added a commit to JasonStoltz/kibana that referenced this pull request Dec 15, 2020
JasonStoltz added a commit to JasonStoltz/kibana that referenced this pull request Dec 15, 2020
@kibanamachine kibanamachine added the backport missing Added to PRs automatically when the are determined to be missing a backport. label Dec 15, 2020
@kibanamachine
Copy link
Contributor

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.

@kibanamachine kibanamachine removed the backport missing Added to PRs automatically when the are determined to be missing a backport. label Dec 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release_note:skip Skip the PR/issue when compiling release notes v7.11.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants