-
-
Notifications
You must be signed in to change notification settings - Fork 173
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
Save draft on chat change #4144
Conversation
maxphilippov
commented
Sep 23, 2024
- resolves Message draft discarded when switching to different chat quickly #3733
OUTDATED: This is a thing we discussed a long time ago, we had a 1 second debounce for saving draft, so if you're in any way fast at switching between different chats you just lose what you were typing right before switching. We were talking about testing something around 200-300ms, I went for 100. |
c9e78c0
to
2896590
Compare
I did keep the original 1 second delay between autosave |
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.
So do you suggest to save the draft on every key press? Because this is what's happening in this MR, and it doesn't seem intentional.
packages/frontend/src/components/composer/ComposerMessageInput.tsx
Outdated
Show resolved
Hide resolved
packages/frontend/src/components/composer/ComposerMessageInput.tsx
Outdated
Show resolved
Hide resolved
dd5b26b
to
3a10e62
Compare
Oops, my bad, rushed that a bit. Didn't notice we have a setState above. I'll draft it for now. Reverted back to 200ms, removed saveDraft from onChange then. Gonna look for a way to maybe flush via ref to messageInputComposer. I don't agree with throttle, since I don't see the point in saving first character immediately and thus pushing next save further in time. Next save is what's more likely to happen on chat change. |
I don't think that's how throttle works. Throttle is never less frequent than debounce. |
Oh, my bad again, for some reason I got memorized that debounce is just throttle but without the inital call (so it calls at the end of time interval while throttle in the beginning). Yeah, makes sense then. |
3a10e62
to
b0a8ac8
Compare
As discussed with @nicodh, I've added a simple throttle implementation and made saveDraft use this one instead of debounce. |
b0a8ac8
to
72b4452
Compare
packages/shared/util.ts
Outdated
clearTimeout(timeout) | ||
timeout = setTimeout( | ||
() => { | ||
if (performance.now() - lastTime >= wait) { |
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.
So if this condition is false, the last call of the throttled function will not invoke fn
?
Why not use an existing package?
packages/frontend/src/components/composer/ComposerMessageInput.tsx
Outdated
Show resolved
Hide resolved
this.props.updateDraftText(text.trim() === '' ? '' : text, chatId) | ||
}, 1000) | ||
}, 200) |
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.
Is the timer supposed to be lowered still?
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 this is sufficient at least in my tests. Somehow the saveDraft seems to be blocking anyway so if I click on a chat or account immediately after typing the click has no effect.
I still managed to have a missing character in the draft or one left over after deleting but I think that's ok. I had to type very fast and click mutiple times on another chat to achieve 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.
so if I click on a chat or account immediately after typing the click has no effect.
Uhh, is this also on the 1.48 release version?
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 this is sufficient at least in my tests.
What I meant is that is it supposed to be lowered to 200 instead of staying at 1000. Because switching to throttle
is supposed to be enough.
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.
Uhh, is this also on the 1.48 release version?
Yes with current master.
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.
Weird, I can't reproduce it.
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 even blocks my mouse pointer whe I try to move it
On current main
I enter fast 5-6 characters and then try to click somewhere - it takes until the draft is saved before I can interact 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.
Sounds bad, I don't think I've ever seen this. Do you think it's worth to make an issue for it?
packages/frontend/src/components/composer/ComposerMessageInput.tsx
Outdated
Show resolved
Hide resolved
if (!this.state.loadingDraft) { | ||
this.saveDraft() | ||
} |
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.
Why is this removed? Is it just a refactor?
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.
These lines exist also in onComponentDidUpdate what doesn't make sense to me, since switching to another chat also triggers onComponentDidUpdate so in the end a fresh loaded draft is immediately saved again. So why not remove them there and leave them 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.
Makes sense.
But the question is if it's directly related to what this commit is doing.
Consider this a nitpick then.
72b4452
to
75ebd78
Compare
75ebd78
to
0398437
Compare
- add throttle to packages/shared/utils.ts - use throttle in saveDraft for messages - remove explicit call to saveDraft when setting state with new text - fixes #3733
0398437
to
ac42e19
Compare
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.
Tested for a while. Appears to work alright.
I also looked at the throttle
implementation again, and it appears to be OK for the current purposes.
If the emoji thing is fine, then let's merge.
Hopefully there are no bad side effects in the refactoring part of this MR.
@@ -13,6 +13,7 @@ | |||
- "Disappearing Messages" dialog not reflecting the actual current value #4327 | |||
- accessibility: make settings keyboard-navigable #4319 | |||
- Fix documentation for --allow-unsafe-core-replacement #4341 | |||
- fix: save message draft every 200ms if message text changed #3733 |
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.
- fix: save message draft every 200ms if message text changed #3733 | |
- fix: save message draft every 400ms if message text changed #3733 |
if (prevState.text !== this.state.text) { | ||
if (!this.state.loadingDraft) { | ||
this.saveDraft() | ||
} | ||
} |
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.
Now the draft does not get saved after you insert an emoji.
Closes #4430. The bug was introduced in #4144. There we made `throttle` accept the `text` argument instead of reading `this.state.text`, and `this.state.text` would get set to `''` after the message has been sent, but then we'd still invoke the throttled function, with the text from the last `onChange` event.
Closes #4430. The bug was introduced in #4144. There we made `throttle` accept the `text` argument instead of reading `this.state.text`, and `this.state.text` would get set to `''` after the message has been sent, but then we'd still invoke the throttled function, with the text from the last `onChange` event.
The bug was introduced in #4144. See #4144 (comment).
Closes #4430. The bug was introduced in #4144. There we made `throttle` accept the `text` argument instead of reading `this.state.text`, and `this.state.text` would get set to `''` after the message has been sent, but then we'd still invoke the throttled function, with the text from the last `onChange` event. This probably doesn't address _all_ the "draft not cleared" issues, e.g. #3586 could be a different issue.
The bug was introduced in #4144. See #4144 (comment).
Closes #4430. The bug was introduced in #4144. There we made `throttle` accept the `text` argument instead of reading `this.state.text`, and `this.state.text` would get set to `''` after the message has been sent, but then we'd still invoke the throttled function, with the text from the last `onChange` event. This probably doesn't address _all_ the "draft not cleared" issues, e.g. #3586 could be a different issue.
The bug was introduced in #4144. See #4144 (comment).