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

[Security Solution][Resolver] Word-break long titles in related event… #75926

Merged
merged 20 commits into from
Aug 27, 2020
Merged

[Security Solution][Resolver] Word-break long titles in related event… #75926

merged 20 commits into from
Aug 27, 2020

Conversation

bkimmel
Copy link
Contributor

@bkimmel bkimmel commented Aug 25, 2020

… description lists

^ and yes, that's ironic.

In order to make meta info titles in the related detail panel more readable and to ensure that they don't overflow onto the data entry next to them, we're changing the style direction to overflow-wrap: word-break on the title container. We're also salting the title text with U+200B (Zero-Width spaces) around punctuation/word boundaries so that when the titles wrap, they wrap around periods, commas, etc. to improve the readability. We're also adding a test to the selector that does that work to confirm that the breaking characters are being set correctly. On the front-end, for User Agents that support it, we're replacing the U+200B spaces with <wbr /> tags because the tags don't get picked up on copy/paste. In the case that the isn't supported, the U+200B are kept as a fallback with the same line-breaking behavior.

Summary

Long property titles in the Related Event Panel description lists can overflow onto the data entry like so:

image

This PR word-breaks the title at the boundary of its element so that it wraps and extends the box it's in instead of overflowing the data entry as pictured above.

Screenshot

image

using the GeneratedText component to prevent the descriptive name from triggering a horizontal scroll:
image

@bkimmel bkimmel marked this pull request as ready for review August 25, 2020 20:35
@bkimmel bkimmel requested review from a team as code owners August 25, 2020 20:35
@bkimmel
Copy link
Contributor Author

bkimmel commented Aug 25, 2020

@elasticmachine merge upstream

@bkimmel bkimmel added v8.0.0 release_note:skip Skip the PR/issue when compiling release notes Feature:Resolver Security Solution Resolver feature Team:Endpoint Data Visibility Team managing the endpoint resolver labels Aug 25, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/endpoint-app-team (Feature:Resolver)

@elasticmachine
Copy link
Contributor

Pinging @elastic/endpoint-data-visibility-team (Team:Endpoint Data Visibility)

Copy link
Contributor

@oatkiller oatkiller left a comment

Choose a reason for hiding this comment

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

Thoughts on using one of these instead? https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-wrap

@@ -23,6 +23,19 @@ import * as selectors from '../../store/selectors';
import { useResolverDispatch } from '../use_resolver_dispatch';
import { PanelContentError } from './panel_content_error';

/**
Copy link
Contributor Author

Choose a reason for hiding this comment

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

❔ It's really only for display purposes, but should we move it to a selector?

@bkimmel
Copy link
Contributor Author

bkimmel commented Aug 26, 2020

Thoughts on using one of these instead? https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-wrap

I got that here now: f9c5278#diff-6b7ec89ef2cc83904892488878bf7257R24

// Seed boundaries beetween word and non-word characters with Zero-width spaces to allow for text to be wrapped when it overflow its container.

return potentiallyLongString.replace(/(\w\W)|(\W\w)/g, (boundary: string) => {
return `${boundary[0]}\u200b${boundary[1]}`;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@oatkiller I ended up pulling this into the selector here. Is this OK?

formattedDate,
] = useSelector(selectors.relatedEventDisplayInfoByEntityAndSelfId)(
processEntityId,
relatedEventId
);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ℹ️ pulled a bunch of this junk into a selector

Copy link
Contributor

@michaelolo24 michaelolo24 Aug 26, 2020

Choose a reason for hiding this comment

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

I see the rationale of having view specific logic like this tied with the component rather than the data. Even though the it doesn't actually change any of the raw data in state, I think of selectors as specifically handling some kind of expensive/calculative logic rather than anything display related. Maybe a bit off here, but I consider this more fitting in the assets.tsx file. I don't think that name is particularly accurate anymore, but the concept of:
here are functions/components that, given some data, apply visual changes
is more representative. The name should be modified/changed when styles are cleaned up, but I think that may be a better compromise that will still allow this to be testable?

Copy link
Contributor

Choose a reason for hiding this comment

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

Thinking out loud a bit, I think something a la a style-utils or something folder with separate file for visual components (cube assets etc...), text modifications, color modifications, and whatever else might make sense or not...probably something I missed here 😂 . Anyways, not really for this PR, but just thinking how we can begin to improve how we handle styles/visual changes

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think most of this stuff here does things that Robert has referred to in the past as "business logic" like counting things, filtering things out, selecting which category to display, etc. (and prefers that they be done in selectors) but I completely agree about thinking a little more deeply about how we organize visual components. I ended up bringing the "break-hinting" stuff back up to the front, b/c @kqualters-elastic made a good point that putting it in the selector just creates another place it can break (and Robert already had that GeneratedText thing done) but that might be a good first entry in that style-utils (until it finds a home in EUI or something later).

import * as event from '../../../../common/endpoint/models/event';
import { ResolverEvent } from '../../../../common/endpoint/types';
import * as selectors from '../../store/selectors';
import { useResolverDispatch } from '../use_resolver_dispatch';
import { PanelContentError } from './panel_content_error';

/**
Copy link
Contributor Author

Choose a reason for hiding this comment

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

ℹ️ moved to selector

@@ -90,6 +56,49 @@ const TitleHr = memo(() => {
});
TitleHr.displayName = 'TitleHR';

const GeneratedText = React.memo(function ({ children }) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Referencing @kqualters-elastic comment from slack, I would cc a member of the EUI team to see about moving this logic there and getting that process started

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I think that's a good idea for the long term, too. Seems like it would be useful in a lot of places. @chandlerprall has always been helpful, maybe he could give us an idea.

Copy link
Contributor

Choose a reason for hiding this comment

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

for any context since I still have a terrible habit of saying too much there and not enough here: long term imo it might make sense to have this logic live in https://github.com/elastic/eui/tree/master/src/components/text as text_wrap.tsx and text_wrap.test.tsx, then used in the base text component conditionally based on the presence of a prop. Add a few snapshot tests that verify the presence of 's where you expect them, add as many test cases as needed

Copy link
Contributor

Choose a reason for hiding this comment

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

Feel free to open an issue in EUI for discussion! It's possible we have this solved via a css utility class.

@bkimmel
Copy link
Contributor Author

bkimmel commented Aug 26, 2020

@monina-n approved earlier via slack conversation

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Build metrics

async chunks size

id value diff baseline
securitySolution 9.5MB +10.9KB 9.5MB

page load bundle size

id value diff baseline
securitySolution 807.8KB +1.0B 807.8KB

History

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

@bkimmel bkimmel merged commit 4294232 into elastic:master Aug 27, 2020
@bkimmel bkimmel deleted the resolver/fix-dl-title-overflow branch August 27, 2020 01:06
bkimmel added a commit that referenced this pull request Aug 27, 2020
#75926) (#76092)

* [Security Solution][Resolver] Word-break long titles in related event description lists

* word-break long titles at non-word boundaries

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Resolver Security Solution Resolver feature release_note:skip Skip the PR/issue when compiling release notes Team:Endpoint Data Visibility Team managing the endpoint resolver v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants