Debounce as an effect

There are several topics here and as well as designed packages related to the problem of debouncing/throttling messages. So we all understand what we mean by debouncing: if we have consequent events with intervals between them less than a certain time value, we want to consume only the last ignoring the rest.

So the question: why is would be not a good idea to have debounced/throttling capabilities made available as effects for example exposed through the Time module? The question is not a proposal, but it means like it sounds, what would be architecturally/ideologically wrong to assume/do such a thing?

1 Like

Any thoughts about this? Maybe @evancz could voice an opinion?

1 Like

As you explain there are multiple debouncing packages. So the first thing to do would be to explain why there are multiple packages, and explain why one of them should be moved into the standard library. This would mean explaining why that one single package (perhaps suitably improved) deprecates the need for all the others. On top of that, you would also have to explain what benefit moving it into the standard library has? What is the problem with it just being a package?

Personally I’d think there are too many different strategies and goals for a single debounce package. On top of which moving something into the standard library has a pretty high bar. So I think moving such a debounce package into the standard library is unlikely. But that’s just my opinion.


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.