-
Notifications
You must be signed in to change notification settings - Fork 130
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
[MM-62462] Plugin link tooltip for Jira plugin opens takes a very long time to load #1145
base: master
Are you sure you want to change the base?
Conversation
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.
A couple of questions from my side:
- Do we also need to update https://github.com/mattermost/mattermost-plugin-github?
- Given this is a breaking change, do we need to mention it in the changelog?
- Do we need to cut a new release of the JIRA plugin and repackage it with v10.5?
@@ -77,18 +77,17 @@ export default class TicketPopover extends React.PureComponent<Props, State> { | |||
return null; | |||
}; | |||
|
|||
componentDidUpdate() { | |||
componentDidMount() { |
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.
Does that mean we query the API on every mouseover?
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, 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.
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.
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?
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 loads depending on the network request resolution. Does that answer your question?
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.
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.
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 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.
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.
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
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.
Ticket created: https://mattermost.atlassian.net/browse/MM-62571
|
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'm still not sure if the number of requests to the JIRA plugin changes with this PR or not. Per https://github.com/mattermost/mattermost-plugin-jira/pull/1145/files#r1910298062, I suppose it doesn't.
QA should check that during testing.
@M-ZubairAhmed let me know when this is merged so I can create a release and update the prepackaged version in MM. |
@M-ZubairAhmed the minimum server version will need to be updated in plugin.json |
Summary
Changes to adopt with the new plugin link tooltip component for this plugin
Ticket Link
Fixes https://mattermost.atlassian.net/browse/MM-62462
Screenshot
Notes
This is a breaking change and should be included in Mattermost v10.5 thats where mattermost/mattermost#29727 is scheduled to be added