$debounce/$throttle helpers

[SimoTod]

What do you think? Would they be useful?

[KevinBatdorf]

Yeah I think they would be pretty useful

[SimoTod]

Debounce is probably not needed since natively silupported by alpine x-on. I can't think of any generic use case. I'll put $throttle on hold since it's weird from a UX point of view (user clicked but nothing happened because they clicked too close to the previous call and they don't get any feedback).

[KevinBatdorf]

I was thinking debounce would be useful with $watch as well as within functions where you can't really use the native debounce.

throttle might be less used, but I guess when it's needed it will be useful. I think it would be okay to include though since it's not a trivial thing for the user to implement themselves.

[KevinBatdorf]

how to implement debounce also confuses beginners I've noticed so probably worth having, especially since it's a fairly common pattern.

[SimoTod]

Can you think of an example where we are watching a property and it gets updated multiple times in a short interval of time. If it's because of an event (like x-on:input), I would debounce the event itself using the native modifier.

However, feel free to pick it up. I'm going to have a look at other features soon (I need to write tests and examples for $inview, I think $cache could be interesting, I've got a half idea for a $await helper accepting promises in x-data, x-text, etc, maybe an $init helper to initialise a variable when you use it (instead of hiding the code in x-init) and finally a $mask(...) helper that you can use with x-spread on input for dates, credit card and money field. I had loads of idea in those days, lol.

[KevinBatdorf]

I guess it would only be useful in a side effect where you would want a secondary action to trigger using a different debounce timer. I'm trying to remember when I've seen people needing it in Discord but can't think of it at the moment. Might be an easy one to implement anyway though. I'll check it out later today.

I'd like to have a helper for everything, but of course not something that would encourage anti patterns, confusion, etc.

I had loads of idea in those days, lol.

Nice! All those sound good. If you get a prototype version up I can help out too.

[SimoTod]

I've got them in my head, hahaha. I'll create a discussion for each one with a rough idea of how they could work (some will use the new utils we added for $component, waitfor and noopproxy opened up for a few new interesting features).