-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
feat(feedback): frontend to display summary #93567
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
base: master
Are you sure you want to change the base?
Conversation
…d uses create_feedback
…sh/cache-ai-summary
…sh/cache-ai-summary merge the branch
great point! I think in most cases we won't, but maybe the read more is meant as a "fallback" so the summary component stays within a max height - which you can set either as a raw number of pixels, or % of screen height. |
feedbackSummaryData.num_feedbacks_used === 0 && | ||
feedbackSummaryData.success === 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.
Can it be a valid case that num_feedbacks_used === 0
and success === true
?
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.
No, that can't be true
…mmary-frontend merge
if (error) { | ||
return <LoadingError message={t('There was an error loading the summary')} />; | ||
} |
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.
should we hide the box completely in this case? unless we provide an option to try again
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.
Yes, we can hide the box for now
<div> | ||
<IconSeer size="xs" /> | ||
</div> |
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.
do we need the div
?
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.
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.
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'll update it to use align-items: baseline, thanks for experimenting!
<FeedbackList /> | ||
</Container> | ||
<SummaryListContainer style={{gridArea: 'list'}}> | ||
{hasFeedbackSummaryEnabled && ( |
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.
if the feedback summary child controls when to render, maybe the flag check should be moved into the child as well. feels a bit disjoint to have separate checks here and in the child
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.
Hmm, looking at now I think the flag check is better in the parent, because we're unnecessarily invoking the useFeedbackSummary
hook otherwise. And the flag deciding whether to render FeedbackSummary
is a different situation compared to an error/pending/tooFewFeedbacks state imo
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.
if we include the flag check in the enabled
part of the hook, then it won't be called unnecessarily right?
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.
Also leads to a dependency in the useFeedbackSummary hook where we have to check the flag there as well
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 we would only need to check it once in the hook file - what do you mean by dependency?
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.
yes, sorry my previous comment sent before I saw yours. If we include it in the enabled
part, it won't be called. What I meant is, if we check the flag it in the parent, the hook won't even be invoked, so checking it in FeedbackSummary would mean we have to actually check it twice (once in useFeedbackSummary as well, as you mentioned). But I don't feel too strongly on this.
/* is this bad design? FeedbackSummary conditionally renders itself if there is a summary, but should that decision be made in its parent instead? causes weird issues like we can't wrap FeedbackSummary with a Container here, it must be wrapped inside the component itself */ | ||
/* the reason i don't generate the summary here instead of in FeedbackSummary is that useFeedbackSummary requires the FeedbackQueryKeys context to be present to be able to parse the start/end date */ | ||
/* another option is to create a new component that wraps the summary and the list, and generate the summary in that new component so the parent would conditionally render the child instead of the child conditionally rendering itself */ |
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.
lets answer this in this PR! Michelle suggested a path forward here: https://github.com/getsentry/sentry/pull/93567/files#r2152739050
/* is this bad design? FeedbackSummary conditionally renders itself if there is a summary, but should that decision be made in its parent instead? causes weird issues like we can't wrap FeedbackSummary with a Container here, it must be wrapped inside the component itself */ | |
/* the reason i don't generate the summary here instead of in FeedbackSummary is that useFeedbackSummary requires the FeedbackQueryKeys context to be present to be able to parse the start/end date */ | |
/* another option is to create a new component that wraps the summary and the list, and generate the summary in that new component so the parent would conditionally render the child instead of the child conditionally rendering itself */ |
// grid-template-columns: minmax(195px, 1fr) 1.5fr; hmm, need to come back to this, i kinda get what it does but it seems a bit sus, but it works better than what was there previously since before there was invalid CSS here | ||
|
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.
what was the invalid CSS?
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 was grid-template-columns: minmax(1fr, 195px) 1fr;
. devtools and ChatGPT told me that is invalid
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.
ahh okay i see. is this what was causing the bug you mentioned? does the current css you have fix that?
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.
Yes this was causing the bug I mentioned, and I think the current CSS I have fixes that (just by playing around with it a bit)
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.
let's clean up this comment before we merge
Jesse mentioned he'll get a design out for this with updated states for loading and if there aren't enough feedbacks. Should we merge and experiment with this for now, and make those changes in a follow-up PR? Or wait to incorporate those changes here. |
i think it's fine to merge what we're happy with here & make changes in a followup PR |
const {selection} = usePageFilters(); | ||
|
||
const normalizedDateRange = normalizeDateTimeParams(selection.datetime); |
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've updated the way the date range filtering is done and from my testing (and looking at the code) this seems to work. Can you please have a look @ryan953 @michellewzhang?
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.
woo, fewer weird things going on!
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.
|
||
const SummaryIconContainer = styled('div')` | ||
display: flex; | ||
flex-direction: row; |
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: the default value for flex-direction
is row
!
|
||
const organization = useOrganization(); | ||
|
||
if (!organization.features.includes('user-feedback-ai-summaries')) { |
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.
can combine this case with the tooFewFeedbacks
case by bringing that one up here
hmm, maybe the error you're seeing is similar to the one Ryan was seeing? like the LLM not generating in the right format. I'm investigating now Edit: looking at Sentry, it does seem that you were facing the same parsing error that Ryan encountered (I am encountering this too) |
Linear ticket: https://linear.app/getsentry/issue/REPLAY-294/frontend-to-display-the-summary
Loading (placeholder) state:

Summary:

Error state:

To be honest I don't know how to implement the "Read more" logic that's on the Figma, image below:

I think I might be able to add the "Read more" on the next line, but I'm wondering that if the response is meant to be only a few sentences, do we need it?
--