Replace input debouncing with a more robust mechanism for de-duplicating queued user events

[wwwillchen]

Fixes #171

[wwwillchen]

I'm actually not sure if this is the right approach now.

Consider the following sequence:

1. user types "a" into input component (user event immediately sent)
2. user types "bc" into input
3. user clicks
4. user types "d"

With my logic, it's possible that when the user event for click is processed, the state will only be "a" because "bc" have been dropped by the user event for "d".

To avoid this issue, we would need to change the algorithm so that we only drop "mergeable" user events (i.e. input events) from the oldest events until we hit a non-mergeable event.

To be honest, I'm wondering if I over-engineered this because I've never actually had someone complain about this race condition before and since I lowered it to 150ms, it's quite improbable in the status quo implementation to hit a race condition (e.g. type in an input and then click a button in less than 150ms).

[richard-to]

I'm actually not sure if this is the right approach now.

Consider the following sequence:

1. user types "a" into input component (user event immediately sent)
2. user types "bc" into input
3. user clicks
4. user types "d"

With my logic, it's possible that when the user event for click is processed, the state will only be "a" because "bc" have been dropped by the user event for "d".

To avoid this issue, we would need to change the algorithm so that we only drop "mergeable" user events (i.e. input events) from the oldest events until we hit a non-mergeable event.

To be honest, I'm wondering if I over-engineered this because I've never actually had someone complain about this race condition before and since I lowered it to 150ms, it's quite improbable in the status quo implementation to hit a race condition (e.g. type in an input and then click a button in less than 150ms).

Yeah that's a good point. So you're saying what potentially could happen is this:

While "a" is being processed by the server, the following events "bc", "click" + "d" happen.

Since these three events get queued up waiting for "a", "bc" gets dropped due to "d"

And you end up with the following events queued: "click", "d"

That does seem worrisome.

In terms of the current debouncing, I agree at 150ms, it would be hard to hit that race condition. I think the only time I've run into that issue is on the CI tests for chat which isn't realistic.

[wwwillchen]

I thought about this some more and a different approach we could do is the essentially send a batch of user events together. For example, whatever is queued, we'll send all of the user events together and process each one (in-order).

In theory, we can optimize this by doing 1 trace mode render loop, call all the event handlers and then do a final render loop if the render loop is mutation free.

I'll close this PR for now and re-open it once we get a clearer signal that the current approach has issues.