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
feat(issue-details): Revise Context UI behind feature flag #68081
Conversation
Bundle ReportChanges will increase total bundle size by 2.73kB ⬆️
|
Separating this out from #68081 since it is a wider change now. Doing this will help simplify the above PR greatly, since it surfaces easy access to context titles and meta values (which store any error states from processing) - `getTitle` function was just moved to utils as is, and renamed to `getContextTitle` - `getContextMeta` was introduced and implemented for all known context sections Here is the meta still being rendered as expected: ![image](https://github.com/getsentry/sentry/assets/35509934/b93d849a-4adf-4fcf-9077-04021c40b6da)
63a1b9d
to
0164c3d
Compare
0164c3d
to
33f222a
Compare
Separating this out from #68081 since it is a wider change now. Doing this will help simplify the above PR greatly, since it surfaces easy access to context titles and meta values (which store any error states from processing) - `getTitle` function was just moved to utils as is, and renamed to `getContextTitle` - `getContextMeta` was introduced and implemented for all known context sections Here is the meta still being rendered as expected: ![image](https://github.com/getsentry/sentry/assets/35509934/b93d849a-4adf-4fcf-9077-04021c40b6da)
4718087
to
15f169d
Compare
…68530) Another PR similar to #68349 to help with simplifying #68081 The goal of this PR is to extract the logic for how we display the known/unknown key value pairs for context items into their own functions and create a util function to easily receive a list of `KeyValueListItem[]` objects which we'll be able to render in our new component. This will prevent them from diverging while we're iterating on the new UI. I had to do this in the verbose helper function way since the logic for converting context keys (e.g. `transaction.op` to `t('Operation Name')`) is unique for EACH context, and lived within the component which rendered the data. Now the data can be accessed outside that specific component, which will make swapping it much easier. It also now defaults to the `raw` data, rather than returning `<StructuredEventData />` components which make the value inaccessible. That formatting can be accessed by calling `getKnownStructuredData` on the result of `getKnownData`. todo - [x] Add test for `getKnownStructuredData` - [x] Ensure CI passes
15f169d
to
f1c4e69
Compare
…68530) Another PR similar to #68349 to help with simplifying #68081 The goal of this PR is to extract the logic for how we display the known/unknown key value pairs for context items into their own functions and create a util function to easily receive a list of `KeyValueListItem[]` objects which we'll be able to render in our new component. This will prevent them from diverging while we're iterating on the new UI. I had to do this in the verbose helper function way since the logic for converting context keys (e.g. `transaction.op` to `t('Operation Name')`) is unique for EACH context, and lived within the component which rendered the data. Now the data can be accessed outside that specific component, which will make swapping it much easier. It also now defaults to the `raw` data, rather than returning `<StructuredEventData />` components which make the value inaccessible. That formatting can be accessed by calling `getKnownStructuredData` on the result of `getKnownData`. todo - [x] Add test for `getKnownStructuredData` - [x] Ensure CI passes
book: { | ||
title: 'This Is How You Lose the Time War', | ||
pages: 208, | ||
published: new Date('2018-07-21'), |
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.
would this be a date or an iso string from the api
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.
Good catch, yeah the API returns ISO strings -- I'll update this.
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.
looks good. css masonry grid layout plz browsers
depth={0} | ||
maxDefaultDepth={0} | ||
meta={contextMeta} | ||
config={{}} |
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.
nit: no need to pass config
, it's not required
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 typed as
config: StructedEventDataConfig | undefined
so its required to declare it. I'll update the type to:
config?: StructuredEventDataConfig
so that I don't have to set it here, and nothing should change.
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.
Sorry, I didn't realize that inner component was being exported. I added the | undefined
because it's easy to forget one of the props when you are doing a recursive render. But for top-level components it's nice to keep the API minimal
value, | ||
meta, | ||
className, | ||
withOnlyFormattedText = false, |
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.
Are you adding this prop to remove the formatting so that you can apply error states to the whole key/value row? I'm not sure if that's the best idea since the annotated text is sometimes only applied to sections of text and not the entire value. It also seems weird to keep a tooltip but not have the highlighted text so you know where to hover.
Such as for size limits, how would this be handled?
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 didn't realize this was something we did. At least as per designs, the background was removed for the <invalid>
/<redacted>
values which was my intention, but you're right that if partially redacted text has a tooltip, we would want to retain it. I'll test this locally and update.
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.
IMO you might want to sync with Vu and see if this requirement can be modified. It would be a lot simpler and more consistent to just keep the annotations the same as they are in the rest of the page, so if that's an option that would be my preference.
meta={contextMeta} | ||
config={{}} | ||
withAnnotatedText | ||
withOnlyFormattedText |
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.
Instead of passing withOnlyFormattedText
is it possible to just pass withAnnotatedText={false}
?
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.
We still want to have annotated text, we just don't want some of the styling that comes packaged with them. This is for transforming null
into italicized <invalid>
or <redacted>
text. The intention is that this new prop spits out primitive text that we can style now, rather than the shaded text with icon tooltips by default (since the design required us moving that to the end of the row)
) : ( | ||
dataComponent | ||
)} | ||
<AnnotatedTextErrors errors={contextErrors} /> |
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 believe that this will only show errors, but not things like data scrubbing? I'd test with an event that has scrubbed values or values that are too long to see what that looks like. We still want those scrubbed values to be highlighted in some way.
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.
That's a good point, I will look into this before merging and add a screenshot/update code if needed. Thanks!
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.
Will update as per review comments before merging
book: { | ||
title: 'This Is How You Lose the Time War', | ||
pages: 208, | ||
published: new Date('2018-07-21'), |
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.
Good catch, yeah the API returns ISO strings -- I'll update this.
depth={0} | ||
maxDefaultDepth={0} | ||
meta={contextMeta} | ||
config={{}} |
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 typed as
config: StructedEventDataConfig | undefined
so its required to declare it. I'll update the type to:
config?: StructuredEventDataConfig
so that I don't have to set it here, and nothing should change.
meta={contextMeta} | ||
config={{}} | ||
withAnnotatedText | ||
withOnlyFormattedText |
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.
We still want to have annotated text, we just don't want some of the styling that comes packaged with them. This is for transforming null
into italicized <invalid>
or <redacted>
text. The intention is that this new prop spits out primitive text that we can style now, rather than the shaded text with icon tooltips by default (since the design required us moving that to the end of the row)
) : ( | ||
dataComponent | ||
)} | ||
<AnnotatedTextErrors errors={contextErrors} /> |
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.
That's a good point, I will look into this before merging and add a screenshot/update code if needed. Thanks!
value, | ||
meta, | ||
className, | ||
withOnlyFormattedText = false, |
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 didn't realize this was something we did. At least as per designs, the background was removed for the <invalid>
/<redacted>
values which was my intention, but you're right that if partially redacted text has a tooltip, we would want to retain it. I'll test this locally and update.
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.
Looks good!
Requires #68530
This PR changes the interface for displaying context items on the issue details page behind the
event-tags-tree-ui
flag.Requires
https://github.com/getsentry/sentry/pull/68530
to create an easy interface to access the formatted context data outside of theContextBlock
components.The masonry layout will be deferred for now to focus on highlights a bit more.
Before
After
todo
update
Okay, was able to double check masking and extremely large values and made some small changes for formatting. Advanced data scrubbing still still shows up with UX friendly tooltips, and I think it's okay they don't show up as errors since they're expected by the organization.