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

feat(issue-details): Revise Context UI behind feature flag #68081

Merged
merged 12 commits into from Apr 15, 2024

Conversation

leeandher
Copy link
Member

@leeandher leeandher commented Apr 2, 2024

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 the ContextBlock components.

The masonry layout will be deferred for now to focus on highlights a bit more.

Before
image

After
image

todo

  • Add tests
  • Add screenshots
  • Double check + screenshots for partial redaction
  • Double check + screenshots for data scrubbing rules as 'error state'

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.

image

Copy link

codecov bot commented Apr 3, 2024

Bundle Report

Changes will increase total bundle size by 2.73kB ⬆️

Bundle name Size Change
sentry-webpack-bundle-array-push 26.29MB 2.73kB ⬆️

leeandher added a commit that referenced this pull request Apr 5, 2024
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)
@leeandher leeandher changed the base branch from master to leander/ref-context-items April 9, 2024 17:39
shellmayr pushed a commit that referenced this pull request Apr 10, 2024
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)
@leeandher leeandher removed the WIP label Apr 10, 2024
Base automatically changed from leander/ref-context-items to master April 10, 2024 19:22
leeandher added a commit that referenced this pull request Apr 10, 2024
…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
@leeandher leeandher requested a review from a team April 11, 2024 17:07
@leeandher leeandher marked this pull request as ready for review April 11, 2024 17:07
c298lee pushed a commit that referenced this pull request Apr 12, 2024
…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'),
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

@scttcper scttcper left a 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={{}}
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

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,
Copy link
Member

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?

CleanShot 2024-04-15 at 09 43 07

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 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.

Copy link
Member

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
Copy link
Member

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}?

Copy link
Member Author

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} />
Copy link
Member

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.

Copy link
Member Author

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!

Copy link
Member Author

@leeandher leeandher left a 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'),
Copy link
Member Author

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={{}}
Copy link
Member Author

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
Copy link
Member Author

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} />
Copy link
Member Author

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,
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 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.

Copy link
Member

@malwilley malwilley left a comment

Choose a reason for hiding this comment

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

Looks good!

@leeandher leeandher merged commit 530e806 into master Apr 15, 2024
42 checks passed
@leeandher leeandher deleted the leander/context-changes branch April 15, 2024 20:36
@github-actions github-actions bot locked and limited conversation to collaborators May 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Scope: Frontend Automatically applied to PRs that change frontend components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants