-
Notifications
You must be signed in to change notification settings - Fork 2.7k
[MM-37048] Do not save drafts until typing has stopped for X milliseconds #8396
Conversation
@@ -46,6 +48,8 @@ import MessageSubmitError from 'components/message_submit_error'; | |||
|
|||
const KeyCodes = Constants.KeyCodes; | |||
|
|||
const CreatePostDraftTimeoutMilliseconds = 500; |
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 initially started lower at 250ms but during my testing it would still fire when I was typing at my normal speed. At 500ms it would consistently only fire after I had a significant pause in my typing.
@hmhealey I know you wanted to lean on the lower end but for this to have the performance impact I'm hoping it will I think it's important that saving doesn't occur during typing.
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.
@jwilander Non-blocking, but is there any benefit to having this constant declared here and the same one declared in create_comment
. Is there any point where we'd want those intervals to be different? If not it might be worth be putting the constant in a constants file.
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 was originally thinking we could lean on the side of having it fire periodically as the user was typing, but I guess if saving the draft is taking as long as we've seen, you're probably right that it's better to be on the safe side with this. If we hear people are losing drafts, we can always back off on the interval.
As for the duplicated constants, I don't think it's important enough to move to the constants file. That thing is bloated with a lot of things that are only used in one or two places if they're even still used at all. I think having two values is fine since I can't see us using this anywhere else, and ideally, both the CreatePost and CreateComment would be rewritten to share this logic entirely anyway.
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.
As for the duplicated constants, I don't think it's important enough to move to the constants file. That thing is bloated with a lot of things that are only used in one or two places if they're even still used at all. I think having two values is fine since I can't see us using this anywhere else, and ideally, both the CreatePost and CreateComment would be rewritten to share this logic entirely anyway.
This was pretty much my exact reasoning.
@jgilliam17 can you test to make sure that post and comment drafts are still saved correctly? |
Found a minor issue with the comment button staying disabled too long that might be related to this change. Going to investigate that |
Fixed the issues. @jgilliam17 can you smoke test commenting on posts/threads with this change too? |
Also @jgilliam17 (and anyone else) please leave the test server up since I'm going to ask some people to create accounts and see if improves performance for them |
@jwilander Do we have a Jira ticket for this? |
No, I didn't create one since it was a bit reactionary. I can create one if you want, though. |
I'll add one as a reminded to test again after merge. 🙂 |
@@ -1,6 +1,8 @@ | |||
// Copyright (c) 2015-present Mattermost, Inc. All Rights Reserved. | |||
// See LICENSE.txt for license information. | |||
|
|||
/* eslint-disable max-lines */ |
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.
Unrelated, but we should really get rid of this...it's more annoying than it helps.
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.
Maybe we could increase the limit or disable it for older files, but I'd like to keep it for newer files since it's nice to discourage people from adding new files with too much stuff going on in them. Only 1/5 on that though.
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.
This looks good to me. I was thinking we might use lodash's debounce utility since that avoids having to manage the timeout manually, but the more I think about it, doing that manually has me less concerned about potentially making mistakes like saving a draft to the wrong channel.
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.
Thanks @jwilander
Tested, looks good to merge.
- Verified post and comment drafts are saved correctly, no issues commenting on threads and single posts.
Test server destroyed |
1 similar comment
Test server destroyed |
…onds (#8396) * Do not save drafts until typing has stopped for X milliseconds * Fix comment box relying on draft stored in redux * Fix tests * Fix another test
…onds (#8396) * Do not save drafts until typing has stopped for X milliseconds * Fix comment box relying on draft stored in redux * Fix tests * Fix another test
* [MM-37048] Do not save drafts until typing has stopped for X milliseconds (#8396) * Do not save drafts until typing has stopped for X milliseconds * Fix comment box relying on draft stored in redux * Fix tests * Fix another test * MM-37048 Temporarily store drafts in localStorage and rehydrate manually to fix persistence issues (#8411) * Temporarily store drafts in localStorage and rehydrate manually to fix persistence issues * Fix console error on reload immediately after typing * Null out saveDraftFrame to prevent potential double saves * Fix draft removal on create_comment and unload in create_post (#8428)
* [MM-37048] Do not save drafts until typing has stopped for X milliseconds (#8396) * Do not save drafts until typing has stopped for X milliseconds * Fix comment box relying on draft stored in redux * Fix tests * Fix another test * MM-37048 Temporarily store drafts in localStorage and rehydrate manually to fix persistence issues (#8411) * Temporarily store drafts in localStorage and rehydrate manually to fix persistence issues * Fix console error on reload immediately after typing * Null out saveDraftFrame to prevent potential double saves * Fix draft removal on create_comment and unload in create_post (#8428) * Fix style * Fix test
Summary
Currently, we were saving drafts for messages being typed into the post and comment textboxes on animation frames which can occur quite frequently. Saving drafts also seems to be less performant on some browser/OS/device combinations than on others. They also fire off a number of dispatches and change redux state which can negatively impact performance too. During some local testing, where I added a console log for each draft save, I was seeing it saved on every single key press which is 1) saving significantly more often than necessary and 2) could be negatively impacting performance, particularly in certain environments.
This is after typing about 100 characters into the post textbox:
In addition some very useful profiles from the community on Firefox are showing
saveDraftFrame
being called about every 100ms during typing and was taking up the majority of the JS processing time in the profile:This PR moves from using animation frames to save the draft to a more controlled
setTimeout
which will only save the draft after 500ms of no typing has occurred (or the component unmounts).Release Note
Ticket link: https://mattermost.atlassian.net/browse/MM-37048