feat: Queue render state updates on a thread

[mofojed]

• Create a thread and queue for applying state updates
• Now callbacks and state updates are all queued on the same thread
• Cleaned up some typing in the Renderer class
• Added a use_render_queue hook and example for showing how to queue state updates
• Fixes Queue state updates to trigger re-render after current update cycle #116
• Tested using the snippet from Queue state updates to trigger re-render after current update cycle #116:

import deephaven.ui as ui
from deephaven.ui import use_state


@ui.component
def foo():
    a, set_a = use_state(0)
    b, set_b = use_state(0)

    print(f"Render with a {a} and b {b}")

    def handle_press():
        set_a(a + 1)
        set_b(b + 1)

    return ui.action_button(
        f"a is {a} and b is {b}", on_press=handle_press
    )


f = foo()

• Ensured that the print out was only printed once per press of the button, and both values stayed the same
• Allow a callable to be passed into the use_state setter function that takes the old value as a parameter. Tested using the following component:

import deephaven.ui as ui
from deephaven.ui import use_state


@ui.component
def bar():
    x, set_x = use_state(0)

    print(f"Render with x {x}")

    def handle_press():
        # Call set_x twice in the same method, using a callable. This should result in x increasing by 2 each time the button is pressed
        set_x(lambda old_x: old_x + 1)
        set_x(lambda old_x: old_x + 1)

    return ui.action_button(
        f"x is {x}", on_press=handle_press
    )


b = bar()

• Tested that trying to update state from the wrong thread throws an error:

import deephaven.ui as ui
import threading
import time
from deephaven.ui import use_state


@ui.component
def foo():
    a, set_a = use_state(0)
    b, set_b = use_state(0)

    print(f"Render with a {a} and b {b}")

    def handle_press():
        def update_state():
            time.sleep(1)
            set_a(a + 1)
            set_b(b + 1)
        # Not using the correct thread
        threading.Thread(target=update_state).start()

    return ui.action_button(
        f"a is {a} and b is {b}", on_press=handle_press
    )


f = foo()

[mofojed]

Should use a ThreadPool so that one users deephaven.ui components doesn't block another users deephaven.ui components.

[mofojed]

Thread pools now exposed to Python: deephaven/deephaven-core#4949

[niloc132]

As above, this seems to imply the following:

foo, set_foo = ui.use_state(None)

#... much later
set_foo(lambda old: do_something_new(old, other_vars))

Did I just assign a function that foo will now be equal to the next time my component renders? Or did I just pass a function that should be called with the old value as a parameter?

[mofojed]

Passed a function that should be called with the old value. If you do want to set a function in a state variable, you need to have it be the return value of an updater function, e.g.

foo, set_foo = ui.use_state(None)

# Need to pass the function back as a result of the updater function
set_foo(lambda old: lambda : print("hello"))

Generally storing a function in a state variable is not a common use case.

[niloc132]

This definition looks the same as below, why do you need it here also?

The T definitions here in the second one also need to union in None, so that None can be safely passed as a possible value.

[mofojed]

I was using @overload incorrectly - I should only have had to define the two @overload and then not define typing in the actual implementation: https://docs.python.org/3/library/typing.html#typing.overload
But when I do that, pylance complains about no typings in the use_state implementation.
In any case, I think I need Python 3.12 to describe the typings correctly using the type parameter syntax on the use_state functions. I'll just get rid of the overload for now and always allow None

[mofojed]

Also see discussion here about default parameters in generic functions: python/mypy#3737 (comment)
Without type parameter syntax to allow for doing something like x, set_x = use_state[int](), which would result in x: int | None, I think the best we can do for now is use type T when an initial_value is passed in, then allow Any when no initial_value is passed in.

# Initial value provided, only accepts the type that was initially provided
x, set_x = use_state(4)

set_x(5)     # This is valid
set_x("foo") # ERROR
set_x(None)  # ERROR

# No initial_value provided, accepts being set to any value
y, set_y = use_state()

set_y(5)     # valid
set_y("foo") # valid
set_y(None)  # valid

def foo(val: int | None):
    # Initial value provided, only accepts the type that was initially provided, including `None`
    z, set_z = use_state(val)

    set_z(5)     # valid
    set_z("foo") # ERROR
    set_z(None)  # valid

    print(z)

At least this way we get proper type checking when you start with an initial_value, and we don't block you from assigning a value if you don't declare an initial_value.

Filed a ticket to improve typing in 3.12: #208

[niloc132]

Thanks, this makes more sense.

[niloc132]

Approved api details, would prefer if @jnumainville gives it a +1 too.