ref(replay): Replace lodash.debounce with custom debounce implementation#6593
ref(replay): Replace lodash.debounce with custom debounce implementation#6593
lodash.debounce with custom debounce implementation#6593Conversation
d543172 to
ee523b8
Compare
size-limit report 📦
|
|
Just a thought: Intuitively I would have implemented the debounce + With that implementation, I think we wouldn't have to track the remaining time and things like that. Was there a particular reason why you went this route? I might be missing something. |
|
This was also my first approach and I already implemented it that way. However, I got replay test errors I couldn't explain, which made me look at the lodash implementation more carefully and I decided to give the one-timeout approach a try. Looking back though, I think I might have missed some details in my first implementation so I'll give the 2-timeouts approach another go. In case I don't get anywhere with it, I'll come back to this version. |
6739731 to
b7ae986
Compare
Lms24
left a comment
There was a problem hiding this comment.
Ok, I've rewritten the debounce implementation with two timers, which should bring down bundle size more than the first version. This required some test adjustments (see my comment)
Also, I moved the function back to the Replay package because we can still pull it into utils if other packages need it.
|
|
||
| captureException(new Error('testing')); | ||
| jest.runAllTimers(); | ||
| jest.advanceTimersByTime(5000); |
There was a problem hiding this comment.
I had to replace a couple of runAllTimers calls with advanceTimersByTime because apparently, two timers don't seem to work with runAllTimers. I'm honestly not entirely sure why and I don't fully understand what might be causing these errors but I think correctness-wise, the debounce function isn't responsible for the test fails.
WDYT, does this change make sense? @billyvg you know these tests best. Is there something I'm missing?
There was a problem hiding this comment.
Not sure, I would think runAllTimers should work -- in any case I think replacing it with advanceTimersByTime is fine.
Should we replace 5000 (and the default for flushMinDelay) with a constant?
There was a problem hiding this comment.
My theory is that the cancellation of the two timers when one of them is invoked might somehow interfere with whatever runAllTimers is doing but tbh this is a guess at best.
Should we replace 5000 (and the default for flushMinDelay) with a constant?
Sure can do
There was a problem hiding this comment.
Sure can do
On second thought, let's do this in a separate PR, just to not clutter this one. I've checked and we're using 5000 quite a lot in tests.
Edit: #6612
| // lodash.debounce is a CJS module, so we need to convert it to ESM first | ||
| commonjs(), |
There was a problem hiding this comment.
Since build changes are always risky, I double checked NPM packages and CDN bundles and they still work with my test apps.
964a080 to
8b0bc87
Compare
We've been using
lodash.debounceto debounce the flushing of replay events. This has a number of drawbacks:This PR replaces lodash's implementation with a heavily simplified version of
debouncewhich just does what we need it for:waittime and gate it with amaxWaitvalueflushandcancelfunction on the debounced function (analogously to lodash).With this change, we can also get rid of the package patch we introduced in #6551 and of the
commonjs()plugin in our build process.closes #6553