Dataclass bindable attributes

[balex89]

It seems handy to make a @dataclasses.dataclass attribute bindable. Unfortunately, there is no clear way to achieve it by following the documentation instructions on binding.BindableProperty as it conflicts dataclass definition with default values (or dataclass.field() function) :

@dataclass
def MyClass:
    a: int = binding.BindableProperty()  # this works (seemingly) fine 

    b: int = 1
    b = binding.BindableProperty()  # but this obviously doesn't 

Fortunately, once constructed, dataclass is not much different from typical user defined class, so one possible approach is to add bindable properties retroactively:

def with_bindable_attrs(dcls: type) -> type:
    for field in dcls.__dataclass_fields__:
        p = binding.BindableProperty()
        p.__set_name__(dcls, field)  # setting name is essential for descriptor to function
        setattr(dcls, field, p)
    return dcls

Then use this as decorator:

@with_bindable_attrs
@dataclasses.dataclass
class MyClass:
    a: int
    b: int = 1

One might want to be able to pick specific attributes only:

def with_bindable_attrs(dcls: type = None, /, *, fields: set = None) -> type | typing.Callable[[type], type]:
    if dcls is None:
        def wrap(cls):
            return with_bindable_attrs(cls, fields=fields)
        return wrap

    if fields is None:
        fields = set(dcls.__dataclass_fields__)

    for field in fields & set(dcls.__dataclass_fields__):
        p = binding.BindableProperty()
        p.__set_name__(dcls, field)
        setattr(dcls, field, p)

    return dcls


@with_bindable_attrs(fields={'a'})
@dataclasses.dataclass
class MyClass:
    a: int
    b: int = 1

One minor drawback to consider is losing access to default values through class attributes (MyClass.b). That doesn't seem to break any common use case though.
Also, this trick doesn't quite work with FastAPI-compatible pydantic dataclasses and might demand a little more effort.

Yet, overall, in my opinion it looks like an easy-to-implement useful out-of-the-box feature, possibly deserving some consideration.

[falkoschindler]

Thanks for sharing this idea, @balex89!
Simplifying the binding support for dataclasses would be a great addition to NiceGUI.

Here's a slightly refined version I came up with:

def bindable_dataclass(dcls: type) -> type:
    if not dataclasses.is_dataclass(dcls):
        raise ValueError('Only dataclasses are supported')
    for field in dataclasses.fields(dcls):
        p = binding.BindableProperty()
        p.__set_name__(dcls, field.name)
        setattr(dcls, field.name, p)
    return dcls

• The name bindable_dataclass avoids abbreviations and confusion with attrs.
• The if-condition enforces the correct order of decoration.
• With dataclasses.fields we get the fields without the need for using internal methods.

For picking individual attributes, I wonder if we can provide something like a bindable_field:

@dataclasses.dataclass
class MyClass:
    x: float = 0.0
    y: float = binding.bindable_field(0.0)

But I'm not sure about the best API. It might depend on the application.

I wonder if there are any more unwanted side effects.
And what do you mean with "FastAPI-compatible pydantic dataclasses"? Can you give an example?

One last thing to consider might be performance: The decorator appears so convenient that users might want to add it to many classes to make them bindable - just in case. This adds a small overhead to every value assignment which might add up for large data structures. On the other hand, using bindings without care can decrease performance anyway.

[balex89]

Thanks for your reply, @falkoschindler !
Love the clean-up you made with the code!

For picking individual attributes, I wonder if we can provide something like a bindable_field:

This did came across my mind as well. Yet I failed to come with a solution to implement it without using of a decorator (or metaclass), which IMHO would make api a little too verbose. Also without "dirty" tricks; e.g. wrapping default values or default factories together with binding logic. This for sure would "run a snowball" of confusing opaque effects for user. I feel like it is essential to preserve any native dataclass logic "as is", including dataclasses.field() features.

That said, considering possible performance issues, forcing a user to consider making each field bindable individually is a great idea. Overall the api would look something like this:

@binding.bindable_dataclass
@dataclasses.dataclass
class MyClass:
    x: float = 0.0
    y: float = binding.bindable_field(0.0)  # this replicates dataclasses.field() logic, 
                                            # also leaving "bread crumbs" for bindable_dataclass

This one I think I can give a try to implement.

And what do you mean with "FastAPI-compatible pydantic dataclasses"? Can you give an example?

All I wanted to say is that proposed implementation approach is (so far) limited to dataclasses module. For example, pydantic data model on surface looks much alike any other "dataclasses":

from pydantic import BaseModel, Field

class MyClass(BaseModel):
    x: float = 0.0
    y: float = Field(0.0)

Yet the way it works inside is much different from dataclasses.dataclass.
Since NiceGUI relies on FastAPI, with pydantic as FastAPI's out-of-the-box native data model solution, seem logical to consider support of pydantic.BaseModel as well.

I wonder if binding.bindable_field interface should universally support every "dataclass" we will agree on worth being supported. Or should we stick with build-in dataclasses (at least for now)?

[falkoschindler]

The bindable field reminds me of a dataclass feature we implemented for our robotics framework RoSys. It uses the config function from the dataclasses_json module to define a new exclude object. When passed as metadata to dataclasses.field, the field will be automatically excluded when the dataclass is converted to JSON.

https://github.com/zauberzeug/rosys/blob/1948dae7c88045e32c1db903377a412987d750fb/rosys/persistence/__init__.py#L9

@dataclass
class A:
    s: str
    b: bool
    e: int = field(default=0, metadata=persistence.exclude)

Maybe we can create something similar, so that you can write

@binding.bindable_dataclass
@dataclasses.dataclass
class MyClass:
    x: float = 0.0
    y: float = dataclasses.field(0.0, metadata=binding.bindable_field)

An advantage would be that we don't have to replicate and document every argument field might accept. But it is a bit verbose, to be honest.

Maybe we better wrap the field?

@binding.bindable_dataclass
@dataclasses.dataclass
class MyClass:
    x: float = binding.field(0.0)
    data: list = binding.field(dataclasses.field(default_factory=list))

I'm not sure. Your bindable_field still seems cleaner.

Anyway, apart from that I think we should ignore Pydantic for now. Even though it follows a similar concept, it is one of multiple alternative libraries we can support later. But I is a good reminder that our API should clearly indicate that this is about dataclasses, e.g. by using a name like bindable_dataclass, allowing to add something like bindable_model later.

[balex89]

Following this discussion, PR #3987 was opened