This looks like a debounce basically. What do you think of replacing this code with Lodash _debounce? See here for an example

1. the callback passed to setTimeout is passed to _debounce instead, with copiedMessageDurationMs as the second param. The result is assigned to a variable eg. debounce
2. onSuccess is replaced with a call to debounce()
3. clearTimeout is replaced with debounce.cancel()

I'm not sure what approach do we use in Comm, but code here feels readable and straight forward and introducing library function would force me to look for API and docs to find out what it does. I find sticking to pure JS is good decision here if lodash doesn't introduce significant simplification.

Initially I thought that replacing this with debounce isn't a good idea. The main reason was that the purpose of debounce is to limit a number of function execution when it is called repeatedly, but here we only need to postpone the execution. I also considered reduced readability caused by using a function that wasn't meant to be used in this context which could be confusing.

But after some time I realized that we're also limiting the number of executions here by clearing the previous timeout and setting a new one. So it seems like debounce can simplify this significantly. I'm going to give it a try.

I'm not sure what approach do we use in Comm, but code here feels readable and straight forward and introducing library function would force me to look for API and docs to find out what it does. I find sticking to pure JS is good decision here if lodash doesn't introduce significant simplification.

I think this is a really good instinct. Too often people introduce indirection that makes code more "concise" (shorter) but less readable, and I agree that readability should be a priority.

That said, I think "debounce" is one of those concepts that all frontend programmers eventually become familiar with. It's kind of like RegEx... it's more concise, but more confusing if you don't understand it. But once you understand it, it can be less confusing. And we're already using it once in the codebase