Could on_press accept an Fn as well as a message instead of a message only about iced HOT 6 CLOSED

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.

from iced.

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.

from iced.

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?

from iced.

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()
    }

from iced.

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.

from iced.

@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: #155 (comment)

from iced.