pub struct Element<'a, Message, Theme, Renderer> { /* private fields */ }Expand description
A generic Widget.
It is useful to build composable user interfaces that do not leak implementation details in their view logic.
If you have a built-in widget, you should be able to use Into<Element>
to turn it into an Element.
Implementations§
Source§impl<'a, Message, Theme, Renderer> Element<'a, Message, Theme, Renderer>
 
impl<'a, Message, Theme, Renderer> Element<'a, Message, Theme, Renderer>
Sourcepub fn new(widget: impl Widget<Message, Theme, Renderer> + 'a) -> Selfwhere
    Renderer: Renderer,
 
pub fn new(widget: impl Widget<Message, Theme, Renderer> + 'a) -> Selfwhere
    Renderer: Renderer,
Sourcepub fn as_widget_mut(&mut self) -> &mut dyn Widget<Message, Theme, Renderer>
 
pub fn as_widget_mut(&mut self) -> &mut dyn Widget<Message, Theme, Renderer>
Sourcepub fn map<B>(
    self,
    f: impl Fn(Message) -> B + 'a,
) -> Element<'a, B, Theme, Renderer>where
    Message: 'a,
    Theme: 'a,
    Renderer: Renderer + 'a,
    B: 'a,
 
pub fn map<B>(
    self,
    f: impl Fn(Message) -> B + 'a,
) -> Element<'a, B, Theme, Renderer>where
    Message: 'a,
    Theme: 'a,
    Renderer: Renderer + 'a,
    B: 'a,
Applies a transformation to the produced message of the Element.
This method is useful when you want to decouple different parts of your UI and make them composable.
§Example
Imagine we want to use our counter. But instead of
showing a single counter, we want to display many of them. We can reuse
the Counter type as it is!
We use composition to model the state of our new application:
use counter::Counter;
struct ManyCounters {
    counters: Vec<Counter>,
}We can store the state of multiple counters now. However, the messages we implemented before describe the user interactions of a single counter. Right now, we need to also identify which counter is receiving user interactions. Can we use composition again? Yes.
#[derive(Debug, Clone, Copy)]
pub enum Message {
    Counter(usize, counter::Message)
}We compose the previous messages with the index of the counter producing them. Let’s implement our view logic now:
use counter::Counter;
use iced::widget::row;
use iced::{Element, Function};
struct ManyCounters {
    counters: Vec<Counter>,
}
#[derive(Debug, Clone, Copy)]
pub enum Message {
    Counter(usize, counter::Message),
}
impl ManyCounters {
    pub fn view(&self) -> Element<Message> {
        // We can quickly populate a `row` by mapping our counters
        row(
            self.counters
                .iter()
                .map(Counter::view)
                .enumerate()
                .map(|(index, counter)| {
                    // Here we turn our `Element<counter::Message>` into
                    // an `Element<Message>` by combining the `index` and the
                    // message of the `element`.
                    counter.map(Message::Counter.with(index))
                }),
        )
        .into()
    }
}Finally, our update logic is pretty straightforward: simple delegation.
impl ManyCounters {
    pub fn update(&mut self, message: Message) {
        match message {
            Message::Counter(index, counter_msg) => {
                if let Some(counter) = self.counters.get_mut(index) {
                    counter.update(counter_msg);
                }
            }
        }
    }
}