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.

Sign up for GitHub

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

[MM-62462] Plugin link tooltip for Jira plugin opens takes a very long time to load #1145

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
+4 −5
Open

[MM-62462] Plugin link tooltip for Jira plugin opens takes a very long time to load #1145

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9f3d9d0
fix
M-ZubairAhmed Jan 9, 2025
eb2e3c6
update min version
M-ZubairAhmed Jan 15, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 3 additions & 4 deletions webapp/src/components/jira_ticket_tooltip/jira_ticket_tooltip.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,18 +77,17 @@ export default class TicketPopover extends React.PureComponent<Props, State> {
return null;
};

componentDidUpdate() {
componentDidMount() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does that mean we query the API on every mouseover?

Copy link
Member Author

@M-ZubairAhmed M-ZubairAhmed Jan 9, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Yes, plugins can implement caching on their side to avoid repeated API calls if they want. However, from the webapp performance perspective, this component will get unmounted and remounted.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Does the JIRA plugin implement such caching? In other words, does the tooltip load as quickly as before the webapp before on the 2nd mouseover?

Copy link
Member Author

@M-ZubairAhmed M-ZubairAhmed Jan 9, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

It loads depending on the network request resolution. Does that answer your question?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Not quite. Previously (If I remember correctly), the webapp would only make one network request per link. Is that still the case? I'm concerned about the number of API requests we make to JIRA, which has caused issues in the past.

Copy link
Member Author

Choose a reason for hiding this comment

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

There was no caching mechanism in place previously, and that remains the case. The webapp still makes a single request per link. However, the performance improvement from the new implementation — particularly by preventing memory leaks present in the previous approach — far outweighs the impact of this minor change.

Copy link
Member

Choose a reason for hiding this comment

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

Testing it on Hub, the current version sort of implicitly caches these because the TicketPopover stays mounted for as long as the user keeps a channel, so it'll only load once per channel switch when the user mouses over a Jira link. The same applies to links on posts in the RHS or Threads view.

If I'm reading the code right, the new logic will make the TicketPopover remount any time the user mouses over and off of a link, so it will make more requests, but I'm not sure how meaningful of a difference that will be unless a user repeatedly does that on purpose. It would be more impactful for keyboard users tabbing over the elements which I'm hesitant to downplay given our focus on accessibility, but I don't know how common that actually is.

Ideally, I think this would be addressed in the Jira plugin by caching it since it's kind of a happy accident that it "cached" data as well as it did before. This is yet another case where loading and caching data effectively is hard.

Overall, I think it's still worth it to make this change to address the side effect of the memory leak despite the potential increase in the number of requests, but I think it'd be good to schedule a followup ticket to improve the caching on the plugin side

Copy link
Member

Choose a reason for hiding this comment

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

Ticket created: https://mattermost.atlassian.net/browse/MM-62571

const issueKey = this.getIssueKey();
if (!issueKey) {
return;
}

const {instanceID} = issueKey;
const {ticketId, ticketDetails} = this.state;
if (!ticketDetails && this.props.show && ticketId) {
if (this.props.show && this.state.ticketId && !this.state.ticketDetails) {
this.props.fetchIssueByKey(this.state.ticketId, instanceID).then((res: {data?: TicketData}) => {
const updatedTicketDetails = getJiraTicketDetails(res.data);
if (this.props.connected && updatedTicketDetails && updatedTicketDetails.ticketId === ticketId) {
if (this.props.connected && updatedTicketDetails && updatedTicketDetails.ticketId === this.state.ticketId) {
this.setState({
ticketDetails: updatedTicketDetails,
});
Expand Down
Loading