Iced: Could on_press accept an Fn as well as a message instead of a message only

[rebo]

Currently TextInput and slider etc allow an Fn to be run that results in a message. This is useful to filter messages that go back into the update.

Could the same be implemented for button.on_press as well? It might be useful to moderate the message that button sends depending on context.

[hecrj]

Thanks for the suggestion!

TextInput and Slider take a function so you can capture their new value. Have you tried something like this?

button.on_press(if some_context { Message::A } else { Message::B })

Is there any reason this may not work for your use case? Could you share a bit more about it? Why is a closure necessary?

[rebo]

Hey hecrj, the other reason for having a closure is that non-iced functions can be triggered. For instance I could implement a counter like the below and keep all my state in the counter without having to store anything in the App model. Useful for encapsulation of local self contained state (i.e. React Hooks)

    fn view(&mut self) -> Element<Message> {

        let (count, count_access) = use_istate(|| 0);

        Column::new()
            .padding(20)
            .push(
                Button::new(Text::new("Increment"))
                    .on_press_callback(move || count_accesss.set(count + 1)),
            )
            .push(Text::new(count.to_string()).size(50))
            .push(
                Button::new(Text::new("Decrement"))
                .on_press_callback(move || count_accesss.set(count - 1)),
            )
            .into()
    }

[hecrj]

Iced is inspired by Elm and The Elm Architecture.

Basically, state mutations are centralized in update and view is a pure function producing a description of the GUI. The whole runtime is built based on the assumption that your view code is pure. This guarantee is what will allow us to build a time travelling debugger in the future!

Hooks (or any kind of mutable callback) are based on side-effects in view code, which is directly against the core foundations of the library.

That said, widgets themselves _can_ have local state, and using something like hooks may be an interesting strategy to track internal state. This should be completely hidden from end-users, though.

[rebo]

Hey sure I understand and I actually like the Elm Architecture very much, just find it a little overkill if you have to run everything through it. It's good that you can have internal states on widgets though.

[dmarcuse]

I'd also be interested in this to support the case where messages can't be cloned: I use an enum for my Message type, and while the values yielded on button presses are unit variants, some of the other variants contain more complicated data that can't be copied. I could start wrapping things in Arc, but that adds significantly more work.

[hecrj]

@dmarcuse After #155, it is possible to have non-cloneable messages by separating your UI interactions from your non-cloneable events. I detailed how to do this here: https://github.com/hecrj/iced/pull/155#issuecomment-573523405