Reactive variables in a data-only class?

[mon]

I have dataclasses that periodically receive information (from a USB device) and update the class's variables when that happens. The updater runs in its own thread.

I can modify the dataclass to make all its variables reactive, but I would like to keep it as a "pure" class with no display components, i.e. not a Widget.

How can I attach these variables to reactive UI? My first attempt was to create a wrapper "display" class that watches the data class, but my UI never updates:

class UsbData(DOMNode):
    var = reactive(0)

test = UsbData()

def test_thread():
    global test
    while True:
        test.var += 1
        time.sleep(0.1)

Thread(target=test_thread, daemon=True).start()

class Display(Widget):
    val = reactive("not yet set")

    def __init__(self, data_class, **kwargs):
        super().__init__(**kwargs)

        def update(val: int):
            self.val = val

        self.watch(data_class, "var", update)

    def render(self):
        return f"{self.val}"

# and then use Display(test) as a widget in my App

If bind a keystroke to perform display.val = test.val, the value updates when I press it, so the thread is definitely working to update the counter.

[davep]

I think you'll find that reactives are designed to be used as part of widgets mounted in the DOM.

If you are wanting to move data from a thread and into your app it's likely better to do that by posting messages. You may also want to read up on Textual's threaded workers.

[mon]

The way I think I understand message passing is there's

• One line in compose or render to display the value
• One line to handle message reception
• One line to define a message type for each piece of data
• One line to handle message sending (but this can be done automatically by my dataclass in a helper function)

So for 100 items, 300 lines of code? And the way I understand reactive (if I can make it work) is one line to render, and that's it.

[davep]

Like I say, it's difficult to really answer this with any confidence because I don't know the problem you're attempting to solve, but as I look at your description above I sense I'd use a single message to indicate that a value has changed, and properties of that message would be what has changed and the new value (for example).

[mon]

Sounds like it could work - I'll slap together some solutions based on these approaches and see which one feels the nicest! Will report back.

[mon]

Alright, I think I've come to a solution I'm happy with.

Some more context for you, hopefully helps explain why I chose this - I have a schema for telemetry being sent back by one or more devices I've attached to my PC. Stuff like temperature, volts, amps, etc. Using that schema, I auto-generate the deserialisation code and shove it into dataclasses. The use of this data might be spread over several screens in my app, so I can't embed the data into a Widget using my code-gen.

My initial implementation was a Rich Live that updated at 10Hz, redrawing the screen each time at a CPU cost of about 5-8%. Works great, but I didn't like the expense.

I experimented a bit with message passing, but it felt expensive to constantly be creating classes to send straight to another class.

So I ended up extending my class:

class UsbData:
    var = 0

    _watchers: defaultdict[str, set]

    def __init__(self):
        self._watchers = defaultdict(set)

    def _inform(self, varname: str):
        for cb in self._watchers[varname]:
            cb(getattr(self, varname))

    def watch(self, varname: str, cb):
        self._watchers[varname].add(cb)

    def unwatch(self, varname: str, cb):
        self._watchers[varname].remove(cb)

My Widget class now calls usb_data.watch('var', update) on init to keep its own reactive up to date. And I can extend my code-gen to automatically call _inform when new data comes in (for testing, I just called it manually in my thread).

This uses about 2-3% CPU with 26 watched elements, which is far more than ncurses which uses 0.2-0.5% (and half the RAM), but Textual's infinitely nicer to use than ncurses, so it's acceptable.