-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Security Solution][Resolver] Word-break long titles in related event… #75926
Conversation
… description lists
@elasticmachine merge upstream |
Pinging @elastic/endpoint-app-team (Feature:Resolver) |
Pinging @elastic/endpoint-data-visibility-team (Team:Endpoint Data Visibility) |
x-pack/plugins/security_solution/public/resolver/view/panels/related_event_detail.tsx
Show resolved
Hide resolved
There was a problem hiding this 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
…kimmel/kibana into resolver/fix-dl-title-overflow
@@ -23,6 +23,19 @@ import * as selectors from '../../store/selectors'; | |||
import { useResolverDispatch } from '../use_resolver_dispatch'; | |||
import { PanelContentError } from './panel_content_error'; | |||
|
|||
/** |
There was a problem hiding this comment.
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?
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]}`; |
There was a problem hiding this comment.
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 | ||
); | ||
|
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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'; | ||
|
||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ℹ️ moved to selector
x-pack/plugins/security_solution/public/resolver/view/panels/related_event_detail.tsx
Outdated
Show resolved
Hide resolved
@@ -90,6 +56,49 @@ const TitleHr = memo(() => { | |||
}); | |||
TitleHr.displayName = 'TitleHR'; | |||
|
|||
const GeneratedText = React.memo(function ({ children }) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
x-pack/plugins/security_solution/public/resolver/store/data/selectors.ts
Outdated
Show resolved
Hide resolved
@monina-n approved earlier via slack conversation |
💚 Build SucceededBuild metricsasync chunks size
page load bundle size
History
To update your PR or re-run it, just comment with: |
#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>
… 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:
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
using the GeneratedText component to prevent the descriptive name from triggering a horizontal scroll: