iced_lazy and Component trait

[hecrj]

This PR introduces a new crate: iced_lazy.

iced_lazy is meant to contain types that are, in one way or another, related to laziness. A container widget is considered lazy when its contents are not strictly computed during an Application::view call. Instead, a lazy widget may choose the compute the contents beforehand, or only when necessary!

Currently, iced_lazy only exposes a new Component trait:

pub trait Component<Message, Renderer> {
    type Event;

    fn update(&mut self, event: Self::Event) -> Option<Message>;

    fn view(&mut self) -> Element<Self::Event, Renderer>;
}

Basically, a Component can be viewed with view, returning widgets that produce some specific Event. A Component can process an Event with update, which may change its internal state and optionally return an application Message.

In other words, a Component can be seen as a sub-application that follows The Elm Architecture, processing internal events and producing messages for the parent application when needed!

The usefulness of this trait becomes apparent when we learn how to use it! The new component::view function has the following signature:

pub fn view<'a, C, Message, Renderer>(
    component: C,
) -> Element<'a, Message, Renderer>
where
    C: Component<Message, Renderer> + 'a,
    Message: 'a,
    Renderer: iced_native::Renderer + 'a,

Any Component implementor can be turned into an Element! This means it is now possible to build custom widgets with its own internal mutable state by leveraging The Elm Architecture. These custom widgets can then be embedded in any iced application without additional wiring.

The new component example uses this new trait to build a NumericInput widget by leveraging composition of the Button and TextInput widgets.

[yusdacra]

Would a PR that adds compenent equalivents of widgets with state be accepted? Behind a feature gate, probably enabled by default. It would mostly remove the need for manual state management, and would make the examples simpler. What do you think about it?

[hecrj]

@yusdacra I'm not sure I follow.

Component does not remove the need for manual state management (i.e. keeping State structs as part of your application state).

[yusdacra]

@yusdacra I'm not sure I follow.

Component does not remove the need for manual state management (i.e. keeping State structs as part of your application state).

Sorry, by "manual" I meant that a component contains its own state, so a user would only need to create a Button component and store that instead of keeping state and passing it to a widget. (if i understood it right, component::view would allow that?)

[hecrj]

@yusdacra No, it doesn't allow that. You'd still need to provide the button::State to build a Button in the first place!

Component is just a way to leverage The Elm Architecture to implement the Widget trait.