How should widgets report variable changes?

[pieterdd]

The dropdown pull request got me thinking about Floem's event handling model. Consider that:

• A checkbox value may change using mouse (click the box) or keyboard (press Space/Enter while widget has focus)
• A dropdown value may change using mouse (click an item) or keyboard (press arrow up/down, or press first letter of an item)

The function creating the widget doesn't care how the value was changed, only what its new value is. For ergonomics reasons, I wouldn't want the caller to have to manually attach mouse and keyboard handlers every time.

I currently see three options:

1. Phase out the use of on_click handlers for reporting data modifications and switch to RwSignal. This would apply to any widget that triggers modifications including checkboxes. While simple to implement, it goes against a commonly applied convention of "data bubbles down, events bubble up". Although I'm inclined to repeat what I'm accustomed to, I have no strong opinion about the convention itself, nor have I researched its pros and cons.
2. Refrain from using write signals and implement an on_update event handler that emits the updated signal value to the caller so they can decide what to do with it. This seems ergonomic, flexible and consistent with how other event handlers work. The main hurdle I see here is that Rust will need to know the type of the new value, and it might be tricky or impossible to express the typing constraints in the current architecture.
3. Refrain from using write signals and let widget functions that support data modification take an update callback function as extra argument. This is again relatively simple to implement, but it feels a bit inconsistent to implement mouse/keyboard event callbacks in one way and change event callbacks in another.

System 1 is in line with what the text input currently does. As a user I think I'd prefer system 2. Systems 2 and 3 offer the user the most control over what happens when a change occurs. System 3 might be an interesting alternative for 2 if it's too complex to implement.

Do you guys have any thoughts on what the best approach would be? Are there any other interesting options I may have missed?

[dzhou121]

2 makes the most sense to me, and it feels the closest to the web as well.

[pieterdd]

I'm open to the possibility, although I need some help envisioning how that could work in practice. My main concern is that since end users may want to make custom widgets as well, the API has to be ergonomic. I quite like that currently you can composite your own widgets by calling a few functions.

[jrmoulton]

I tried converting checkbox to a view and it was a pain.

It required implementing several the view trait methods for children and for event. The event handling was a pain. I had to store an rwsignal in the struct as well and update that on state change so that the svg could get updates.

It worked and wasn't that bad but for as simple as it should have been it was a pain and the work would have to be repeated for labeled checkbox. I'm not sure it's the right approach.

[pieterdd]

Would a generic implementation of a wrapping View that is able to emit updates reduce friction? Something like:

pub fn checkbox(
    checked: ReadSignal<bool>,
) -> impl UpdateableView<bool> {
    let view = UpdateableView::new();
    let inner = container(checkbox_svg(checked)
        .keyboard_navigatable()
        .on_click_stop(move |event| {
            view.emit_update(event, !checked.get());
        })
        .on_key_down(
            Key::Named(NamedKey::Enter),
            ModifiersState::empty(),
            move |event| {
                view.emit_update(event, !checked.get());
            },
        ));
    view.inner(inner)
}

[sudormrfbin]

Re: converting checkbox to a view, can't it be done similar to how ToggleButton is implemented? As for repeated work on the labeled_* variants, we could add a field on the Checkbox struct that takes an Option<String> and a label() method to set it.

[pieterdd]

I'm sure it could be done, but keep in mind that it makes development of custom widgets by users harder too. Users should be able to create a custom widget simply by calling a bunch of view functions. That's the power of Floem, and it's consistent with how Jetpack Compose works.

A goal for Floem is to be ergonomic, so I'd strongly recommend against this.

[pieterdd]

As a baseline for how easy to use system 2 should ideally be, I'll share a possible implementation of system 3 here:

The caller

checkbox(is_checked, move |value| {
    set_is_checked.set(value);
}),

The widget implementation

pub fn checkbox(
    checked: ReadSignal<bool>,
    on_update: impl Fn(bool) -> () + Copy + 'static,
) -> impl View {
    checkbox_svg(checked)
        .keyboard_navigatable()
        .on_click_stop(move |_| {
            on_update(!checked.get());
        })
        .on_key_down(
            Key::Named(NamedKey::Enter),
            ModifiersState::empty(),
            move |_| {
                on_update(!checked.get());
            },
        )
}

To account for sneaky caveats like lifetimes I checked that this compiles. As expected the syntax is fairly straightforward, if inconsistent with the current .on_event() methods. Although I hope system 2 works out, system 3 could be a plan B.

Some fine print: I noticed that even without a key down handler, checkbox responds to Space and Enter when focused. I assume Floem implicitly fires the click handler to handle Space/Enter. This may work for checkbox, but isn't perfect from a semantic perspective and does not cover the needs of every widget. Dropdowns for example tend to react when you press the first letter of one of the dropdown items. So an on_update callback still seems like a useful abstraction.

[dominikwilkowski]

To your finer point should we not pass in an event to the on_update closure which contains the reason the change happened in this case the either a button event or a click event? Space or Enter or Mouse etc...?

[pieterdd]

Do you have a specific use case in mind where the caller would want to know the input source that triggered the data change?

[dominikwilkowski]

It should not just be an enum with values Mouse, Keyboard etc... the event argument passed into the event handler should contain things like mouse position, rect position/dimension, id of view etc etc... I would love to get an id back for instance to manage focus easier.
But to your question an example off the top of my head for needing to know if the input was triggered by keyboard vs mouse would be focus_visible or other a11y features. But I'm sure there are more use-cases?
Consistency across widgets? With multiple types of widgets (checkboxes, buttons, radio buttons), passing the event type ensures a consistent approach to handling events across different types of widgets.

Also you could re-use on change closures if we passed in view ids so the function would be able to determine what button has been pressed by inspecting at the view id?

[pieterdd]

Supporting a11y is a big topic to unpack, meriting a separate conversation. The outcome of that conversation might be that certain information like Id is exposed, although ideally Floem widgets would cover a11y needs out of the box. In that case you might not even need to use these parameters. But I suggest to get the foundations of event handling sorted out first.

Consistency across widgets? With multiple types of widgets (checkboxes, buttons, radio buttons), passing the event type ensures a consistent approach to handling events across different types of widgets.

That could indeed be an argument for forwarding the event parameter, or providing something similar. I don't have a strong opinion. On the one hand, users should be given whatever they need to build a good UI. On the other hand, the more your API exposes, the higher the maintenance burden and potential for breaking changes, so I wanna be thoughtful about this. Then again, it's still 0.x software, so we could flip a coin and reverse the decision later if needed.

[dominikwilkowski]

Easy.

ideally Floem widgets would cover a11y needs out of the box
Accessibility is hard and very contextual. A component lib won't be able to automate a11y needs to 100% so giving people escape hatches so that for their need the a11y experience is good would be important.

I think taking the lead from the web here would be a good starting point.

[pieterdd]

The update mechanism involving value_container and on_update has been merged into main. I hope it'll be convenient to use, and I'm sure it can still be tweaked if needed.