Allow Component::State to be initialized.

[edfloreshz]

Iced does not currently allow to initialize the state of a component, it might be useful to have a method that runs the first time the component is initialized.

I propose something like this to be implemented:

pub trait Component<Message, Renderer> {
    /// The internal state of this [`Component`].
    type State: Default;

    /// The type of event this [`Component`] handles internally.
    type Event;

    /// Initializes the [`State`](Component::State) the first time the component is initialized.
    fn init(&self, state: &mut Self::State);

    /// Processes an [`Event`](Component::Event) and updates the [`Component`] state accordingly.
    ///
    /// It can produce a `Message` for the parent application.
    fn update(
        &mut self,
        state: &mut Self::State,
        event: Self::Event,
    ) -> Option<Message>;

    /// Produces the widgets of the [`Component`], which may trigger an [`Event`](Component::Event)
    /// on user interaction.
    fn view(&self, state: &Self::State) -> Element<'_, Self::Event, Renderer>;
}

It would allow for things like this:

struct Counter {
    value: u8
}

struct CounterState {
    value: u8
}

impl Component for Counter {
    type State = CounterState;
    type Event = ();

    fn init(&self, state: &mut Self::State) {
        state.value = self.value
    }
}

Preventing the value from being reset when the component is re-rendered and allowing for state to be initialized without having to do weird tricks in the view and update method.

Current implementation of this already exists in Frui, here's an example.

[alex13sh]

why initialization is needed when there is a Default for the state. Well, if state initialization is needed, then it's better to do it as create_state with a default implementation that will return the default state.

[edfloreshz]

Having a default implementation does not allow the State to receive data from the parent, if I wanted to initialize my counter at 100 it wouldn't be possible in a straightforward way.

[hecrj]

The internal state of a widget is internal for a reason! view should not be able to have any effect on it whatsoever.

There is no such thing as "initializing" a widget in iced.

view is pure and stateless; and any kind of stateful behavior (like initializing something) goes against this idea.

[edfloreshz]

Got it, thanks 👍🏼

[13r0ck]

Linking the discord discussion here:
https://discord.com/channels/628993209984614400/1031395561192034364

The consensus appears to be a no.