Challenging the Logic Behind "active" in Debounce Function

[QTimort]

Hello, @MarlonPassos-git,

I'm struggling to grasp the rationale behind the active variable in the debounce function, which is puzzlingly set to false when cancelling a debounce. This approach effectively cripples the main purpose of the function, offering no clear reason or method for reactivation. The supposed aim of the cancel function is to clear a timer, not to render the whole debounce mechanism useless. This not only makes zero sense but also starkly contrasts with lodash's behavior even though I'm aware this isn't supposed to be a 1-1 lodash replica. Could you shed light on this interesting design of yours?

https://github.com/rayepps/radash/blame/03dd3152f560414e933cedcd3bda3c6db3e8306b/src/curry.ts#L131

[MarlonPassos-git]

Hello @QTimort.

I remember we discussed the possibility of creating a method to re-enable debounce, but at the time we couldn't find a clear reason why someone would disable and then re-enable debounce. The idea of opting out was the only approach we considered at the time. This lack of clear usage scenario is why we haven't implemented a method to reactivate.

If you have any specific use cases in mind for this functionality, please share. Tag @rayepps in the conversation, and if he agrees, I'm willing to create a Pull Request adding this feature.

You can see:
#87
#118

[QTimort]

Hello @MarlonPassos-git and @rayepps,

I appreciate your prompt response to my initial query regarding the debounce function's design, specifically about the active variable behavior. I understand the previous discussions led to the current implementation due to a lack of clear use cases for re-enabling the debounce. However, I'd like to present a scenario where the current design may limit functionality and propose a potential enhancement.

Current Limitation:
The current implementation permanently deactivates the debounce on canceling, which could lead to a scenario where a user might want to temporarily disable the debounce effect without losing the ability to reactivate it later. For example, in a real-time collaborative environment, a user might temporarily want to disable debounce to see live changes instantly. However, the current design doesn't allow re-enabling, which forces the user to either live with the permanent decision or instantiate a new debounce function, which is not optimal.

Proposed Enhancement:
A more flexible approach would be allowing temporary disabling of the debounce effect. This could be achieved by setting the debounce delay to 0. Furthermore, to enhance this functionality, we could introduce a simple function to stop the setTimeout call, allowing users to cancel a debounce without permanently disabling it. This change would not only align more closely with common debounce behavior (as seen in libraries like lodash) but also provide users with greater control over the function's behavior.

Benefits:

1. Flexibility: Users gain the ability to temporarily disable and re-enable debounce, accommodating diverse use cases.
2. Consistency: Aligns more closely with common debounce implementations, reducing the learning curve for new users of the library.
3. Control: Provides users with greater control over the debounce behavior, enhancing the usability of the library.

I believe this enhancement would make the debounce function more versatile and user-friendly. I'm eager to hear your thoughts on this proposal and am willing to contribute to the discussion or development if needed.

[aleclarson]

Hi @QTimort and @MarlonPassos-git, I appreciate the willingness to collaborate with careful thought and consideration you both exude. Let me invite both of you to join the effort over at radashi-org/radashi, a new actively maintained fork that's open to adding more maintainers (like you). ✌️