Add debounce and condition args to reactpy.event

[shawncrawley]

I have found that the biggest shortcoming to using ReactPy vs ReactJS is when it comes to rapidly firing events - such as onChange attached to a text input or onMouseMove on a large div. I had the idea of being able to either pass debouce=<seconds> to a ReactPy event and/or pass a condition that can evaluate in javascript to determine whether the event should actually be sent to the ReactPy backend.

Debounce example:

from reactpy import html, event, component, use_state

@component
def MyTextArea():
    text, set_text = use_state("")
    return html.textarea({"rows": "4", "cols": "50", "onChange": event(lambda e: set_text(e.target.value), debounce=1)})

Condition example:

from reactpy import html, event, component, use_state

@component
def MyForm():
    submitted, set_submitted = use_state(False)
    return html.div(
        html.form({"onSubmit": lambda e: (e.prevent_default, set_submitted(True))}, 
            html.input({"type": "text", "onChange": event(lambda e: set_submitted(True), condition='e.key == "Enter"')}),
            html.button({"type": "submit"}, "Submit"),
            key="form"
        ),
        html.div("Submitted!") if submitted else None
    ) 

Any thoughts, concerns, or shortcomings?

[Archmonger]

Debounce: This is lucky timing on my part, already on it. A few hours before you posted, I had committed debounce logic to PR #1340 to resolve issues with speeding up the reactpy-django test suite. I will work on making the debounce implementation more customizable.

Condition: Rather than a condition variable, it seems the problem would be solved better by #894. I've cleaned up that ticket to more clearly describe what the end goal is.

[SHEWALERUSHI]

The debounce addition sounds like a good improvement, especially for high-frequency events like onChange and onMouseMove, where sending every event to the backend can quickly become expensive.

One possible consideration could be allowing both debounce and throttle strategies depending on the use case. Debounce works well for text inputs, while throttling might be more suitable for continuous interactions like mouse movement or scrolling.

Handling some filtering on the client side before sending events to ReactPy could also help reduce unnecessary backend updates and improve perceived responsiveness.

Looking forward to seeing how the customizable debounce implementation evolves.

[Archmonger]

I can see the usability improvements for throttle.

Example interfaces and my thoughts below about what this interface would look like from ReactPy's end.

# Example interface #1
# Efficient but does not have any similar/identical ReactJS or JavaScript analogue, which goes against
# the theme of ReactPy. The event decorator was intended to be deprecated with v2.
@event(debounce=200, throttle=1000)
def onClick(event):
    ...


# Example interface #2
# Slightly less efficient. Currently, in v2.0.0 we AST parse the function's `__code__` to allow
# `event.preventDefault()` to exist. The parsing is cached, so the performance penalty is negligible.
# However, since `debounce` and `throttle` would ingest parameters this scenario would get more
# complex. This might mean that if the user provides a variable as a parameter, then we might
# need to default to a safe value until the first server to client event communication occurs. Probably not
# a huge problem? Most people would use a static value, and in comparison the decorator variant
# (example #1) would only support static values to begin with.
def onClick(event: Event):
    event.debounce(200)
    event.throttle(1000)


# Example interface #3
# This would not provide per-event customization, which is likely a deal-breaker.
reactpy.config.EVENT_DEBOUNCE.set(200)
reactpy.config.EVENT_THROTTLE.set(1000)