Is there a pattern for view() as method on Rc<RefCell<Something>>?

[sowbug]

I don't know whether this is a Rust or Iced question. Apologies if I've guessed wrong.

I'd like to implement view() and update() as methods on various structs that are internal to my app. Many of these structs are wrapped in either Rc<RefCell<>> or Weak<RefCell<>>. I can't seem to produce an Element<Message> without triggering an E0515 error (cannot return value referencing temporary value).

I've modified the 0.4 branch's counter example to demonstrate the issue. I've also published this code as a gist and a diff, which I hope will make it easier to grok what's going on.

Below are the error and the code:

$ cargo build
   Compiling iced-sandbox v0.1.0 (/home/miket/src/iced-sandbox)
error[E0515]: cannot return value referencing temporary value
  --> src/main.rs:82:17
   |
82 |                 column.push(item.borrow_mut().view())
   |                 ^^^^^^^^^^^^-----------------^^^^^^^^
   |                 |           |
   |                 |           temporary value created here
   |                 returns a value referencing data owned by the current function

use iced::Sandbox;
use iced::{button, Alignment, Button, Column, Container, Element, Settings, Text};
use std::cell::RefCell;
use std::rc::Rc;

pub fn main() -> iced::Result {
    Counter::run(Settings::default())
}

#[derive(Debug, Default)]
struct Thing {
    name: String,
}

impl Thing {
    pub fn view(&mut self) -> Element<Message> {
        Container::new(Text::new(self.name.clone())).into()
    }
}

#[derive(Debug, Default)]
struct OtherStruct {
    pub things: Vec<Rc<RefCell<Thing>>>,
}

impl OtherStruct {
    fn new() -> Self {
        Self {
            things: vec![Rc::new(RefCell::new(Thing {
                name: "hello".to_string(),
            }))],
        }
    }
}

#[derive(Default)]
struct Counter {
    value: i32,
    increment_button: button::State,
    decrement_button: button::State,
    o: OtherStruct,
}

#[derive(Debug, Clone, Copy)]
enum Message {
    IncrementPressed,
    DecrementPressed,
}

impl Sandbox for Counter {
    type Message = Message;

    fn new() -> Self {
        Self {
            o: OtherStruct::new(),
            ..Default::default()
        }
    }

    fn title(&self) -> String {
        String::from("Counter - Iced")
    }

    fn update(&mut self, message: Message) {
        match message {
            Message::IncrementPressed => {
                self.value += 1;
            }
            Message::DecrementPressed => {
                self.value -= 1;
            }
        }
    }

    fn view(&mut self) -> Element<Message> {
        let other_view = self
            .o
            .things
            .iter_mut()
            .enumerate()
            .fold(Column::new(), |column, (_, item)| {
                column.push(item.borrow_mut().view())                   <------ THIS IS LINE 82
            });
        Column::new()
            .padding(20)
            .align_items(Alignment::Center)
            .push(
                Button::new(&mut self.increment_button, Text::new("Increment"))
                    .on_press(Message::IncrementPressed),
            )
            .push(Text::new(self.value.to_string()).size(50))
            .push(
                Button::new(&mut self.decrement_button, Text::new("Decrement"))
                    .on_press(Message::DecrementPressed),
            )
            .push(other_view)
            .into()
    }
}

I think I get what's happening: the lifetime of the result is inferred to be no longer than the lifetime of self.view(), and because self was obtained from borrow_mut(), it's considered a temporary value within the scope of the fold(). But intuitively, it seems that Element<Message> is self-contained; it consists of a new Container wrapping a new Text, and I even cloned the name String to emphasize that it's independent of the Thing struct.

The Rust version of this question: have I analyzed the problem correctly? How do I express that Element<Message>'s ownership can pass to the caller of Thing::view()?

The Iced version of this question: is there a common pattern among Iced experts that allows something with a "weird" lifetime (Rc, etc.) to produce an Element<_> whose lifetime is independent of that something?

Thanks.

P.S. The reason I wanted to stick the view() and update() right onto the app's internal structs, rather than creating new structs that the Iced Sandbox/Application owns, is that I don't want to have to expose all the API surface area that the external structs would need to create a competent view() from them. I'm hoping that the entire relationship between my app and Iced would be Element<_>s out, and Messages in, with neither of them having references to their internal data (and thus lifetime questions). I thought that was part of the beauty of the Elm architecture, but I seem to have mucked it up by having an app that wraps everything in Rc<>.

[sowbug]

Yeesh, I have a complicated solution. I'll make a simplified example shortly, but here's the idea:

• Each thing that I want to implement Iced methods like view() and update() has a Weak pointing to itself. I made a contorted kind of new() that squirrels this away upon construction. It's more complicated than merely Rc::new_cyclic() because mine are all Rc<RefCell<>>.
• Those things also implement a trait that's named something like MakesViewableResponder with one method fn make_viewable_responder(&mut self) -> Option<Box<dyn IsViewable>>. The IsViewable trait, for now, has just local versions of view() and update().
• The Application still has an OtherStruct, but now it has a Vec to Weak<RefCell<dyn MakesViewableResponder>>. These are actually the internal structs that I originally wanted to implement view() and update() directly.
• When it loads, Application iterates through that Vec, asking each one to make an IsViewable. That's a small struct that has only a weak target pointer back to the struct that it wants to render. It knows how to satisfy view() and update() via pub(crate)-visibility methods on the original structs, and because each IsViewable is pretty tightly coupled to its parent MakesViewableResponder, I don't have to stress out too much about making nice long-lasting APIs just to enable creation of Iced Elements or response to Iced Messages.

This seems to satisfy Rust that the lifetime of the Element<Message> created by view() is tied to the lifetime of the IsViewable, which is owned by the Application (even though the Element was created by referring to the underlying struct that's wrapped in the Rc<RefCell<>>). That looks a lot more like the ownership model that I've seen in the other Iced examples.

I'm sure someone will reply in this thread with something like "oh you just needed a lifetime specifier <'a> here and here," but I'm reasonably happy with this solution.

[sowbug]

Here is the code (with a gist for syntax highlighting). I hope it helps someone else doing the same thing. I'm open to suggestions for other approaches.

use iced::Sandbox;
use iced::{button, Alignment, Button, Column, Container, Element, Settings, Text};
use std::cell::RefCell;
use std::rc::{Rc, Weak};

pub fn main() -> iced::Result {
    Counter::run(Settings::default())
}

#[derive(Debug, Clone, Copy)]
enum Message {
    IncrementPressed,
    DecrementPressed,
}

/// All the methods we expect to see on an Iced entity.
trait IsViewable {
    fn view(&mut self) -> Element<Message>;
    fn update(&mut self, message: Message);
}

struct ThingViewer {
    target: Weak<RefCell<Thing>>,
}

impl IsViewable for ThingViewer {
    fn view(&mut self) -> Element<Message> {
        if let Some(target) = self.target.upgrade() {
            Container::new(Text::new(&target.borrow().name)).into()
        } else {
            panic!()
        }
    }
    fn update(&mut self, _message: Message) {
        todo!()
    }
}

/// Creates a small struct that exposes the IsViewable methods and
/// implements them in terms of the "parent" struct that created it.
trait ViewerMaker {
    fn make_viewer(&mut self) -> Option<Box<dyn IsViewable>>;
}

/// A factory that makes the IsViewable, except that this factory
/// is specific to one instance of Thing, not static for all
/// Things. Note that this assumes that it was already set up
/// with a me pointer to itself.
impl ViewerMaker for Thing {
    fn make_viewer(&mut self) -> Option<Box<dyn IsViewable>> {
        if self.me.strong_count() != 0 {
            Some(Box::new(ThingViewer {
                target: Weak::clone(&self.me),
            }))
        } else {
            // This Thing was set up incorrectly.
            None
        }
    }
}

/// This is the structure that existed in the original app, before
/// we wanted to add an Iced GUI to it.
#[derive(Debug, Default)]
struct Thing {
    me: Weak<RefCell<Self>>,
    name: String,
}

impl Thing {
    // new() isn't public, because it's usually an error to
    // instantiate without me set properly.
    fn new() -> Self {
        Self {
            name: "hello. I was built using the IsViewer trait.".to_string(),
            ..Default::default()
        }
    }

    // Wraps the result of new() in Rc<RefCell<>>, and sets up
    // me to point to itself.
    //
    // Rc::new_cyclic() should make this easier, but I couldn't get it to work
    // with an interior RefCell.
    // https://doc.rust-lang.org/std/rc/struct.Rc.html#method.new_cyclic
    pub fn new_wrapped() -> Rc<RefCell<Self>> {
        let wrapped = Rc::new(RefCell::new(Self::new()));
        wrapped.borrow_mut().me = Rc::downgrade(&wrapped);
        wrapped
    }
}

#[derive(Debug, Default)]
struct OtherStruct {
    pub things: Vec<Rc<RefCell<Thing>>>,
}

impl OtherStruct {
    fn new() -> Self {
        Self {
            things: vec![Thing::new_wrapped()],
        }
    }
}

#[derive(Default)]
struct Counter {
    value: i32,
    increment_button: button::State,
    decrement_button: button::State,
    o: OtherStruct,
    viewers: Vec<Box<dyn IsViewable>>,
}

impl Sandbox for Counter {
    type Message = Message;

    fn new() -> Self {
        let mut r = Self {
            o: OtherStruct::new(),
            ..Default::default()
        };

        for viewer_maker in r.o.things.iter_mut() {
            if let Some(viewer) = viewer_maker.borrow_mut().make_viewer() {
                r.viewers.push(viewer);
            }
        }

        r
    }

    fn title(&self) -> String {
        String::from("Counter - Iced")
    }

    fn update(&mut self, message: Message) {
        match message {
            Message::IncrementPressed => {
                self.value += 1;
            }
            Message::DecrementPressed => {
                self.value -= 1;
            }
        }
    }

    fn view(&mut self) -> Element<Message> {
        let other_view = self
            .viewers
            .iter_mut()
            .enumerate()
            .fold(Column::new(), |column, (_, item)| column.push(item.view()));
        Column::new()
            .padding(20)
            .align_items(Alignment::Center)
            .push(
                Button::new(&mut self.increment_button, Text::new("Increment"))
                    .on_press(Message::IncrementPressed),
            )
            .push(Text::new(self.value.to_string()).size(50))
            .push(
                Button::new(&mut self.decrement_button, Text::new("Decrement"))
                    .on_press(Message::DecrementPressed),
            )
            .push(other_view)
            .into()
    }
}

[13r0ck]

Ya the iced todos example implements view and update on structs without needing RC
https://github.com/iced-rs/iced/blob/master/examples/todos/src/main.rs#L302

[tarkah]

In 99% of cases, you absolutely shouldn't need interior mutability anywhere across the app. I highly recommend targeting master instead of 0.4 and using the new pure API. This will make things a lot more simple and it's more natural as view(&self) is now immutable.

Here is a relevant snippet for you (using iced from master / pure), where you can hold an array of some state for an iterable component of your app:

use iced::widget::{column, container};
use iced::{executor, Application, Command, Element, Length, Settings, Theme};

use self::thing::Thing;

fn main() {
    App::run(Settings::default()).unwrap();
}

#[derive(Debug, Clone)]
enum Message {
    Thing(usize, thing::Message),
}

struct App {
    things: Vec<Thing>,
}

impl Application for App {
    type Executor = executor::Default;
    type Message = Message;
    type Theme = Theme;
    type Flags = ();

    fn new(_flags: Self::Flags) -> (Self, Command<Message>) {
        (
            App {
                things: vec![Thing::default(); 10],
            },
            Command::none(),
        )
    }

    fn title(&self) -> String {
        "Example".into()
    }

    fn update(&mut self, message: Message) -> Command<Message> {
        match message {
            Message::Thing(index, message) => {
                if let Some(thing) = self.things.get_mut(index) {
                    if let Some(event) = thing.update(message) {
                        match event {
                            thing::Event::Delete => {
                                self.things.remove(index);
                            }
                        }
                    }
                }

                Command::none()
            }
        }
    }

    fn view(&self) -> Element<Message> {
        let things = column(
            self.things
                .iter()
                .enumerate()
                .map(|(index, thing)| {
                    thing
                        .view(index)
                        .map(move |message| Message::Thing(index, message))
                })
                .collect(),
        )
        .spacing(5);

        container(things)
            .width(Length::Fill)
            .height(Length::Fill)
            .center_x()
            .center_y()
            .into()
    }
}

mod thing {
    use iced::widget::{button, container, row, text};
    use iced::{theme, Alignment, Element, Length};

    #[derive(Debug, Clone)]
    pub enum Event {
        Delete,
    }

    #[derive(Debug, Clone)]
    pub enum Message {
        Increment,
        Decrement,
        Delete,
    }

    #[derive(Debug, Default, Clone)]
    pub struct Thing {
        count: u64,
    }

    impl Thing {
        pub fn update(&mut self, message: Message) -> Option<Event> {
            match message {
                Message::Increment => {
                    self.count += 1;
                    None
                }
                Message::Decrement => {
                    self.count = self.count.saturating_sub(1);
                    None
                }
                Message::Delete => Some(Event::Delete),
            }
        }

        pub fn view(&self, index: usize) -> Element<Message> {
            let count = self.count;

            container(
                row![
                    text(format!("Thing {index} - Count: {count}")).width(Length::Fill),
                    button(text("Increment")).on_press(Message::Increment),
                    button(text("Decrement")).on_press(Message::Decrement),
                    button(text("Delete"))
                        .on_press(Message::Delete)
                        .style(theme::Button::Destructive)
                ]
                .spacing(5)
                .align_items(Alignment::Center),
            )
            .max_width(400)
            .into()
        }
    }
}

[sowbug]

Thanks for the comprehensive sample code. I was able to modify the original sample to make view() take an immutable self, and then remove the interior RefCell<>. It then built! The next question is whether I can remove RefCell<> from my app (not just the sample code). I thought I needed it when I started out building the app, but I've gotten more experienced with Rust since then, and I might now know how to eliminate it.

I'll consider moving from iced 0.4 to a more recent version, but for now I think I can isolate the change by simply making my own view() methods immutable. They resemble Iced's Application::view() method but aren't actually the same trait, so I can try it without moving away from 0.4.

Thanks again! I'll mark your answer and reopen the thread if I make any progress worth reporting.

(Quick edit: ah, yeah, looks like I'll have to abandon 0.4 if I want to create any nontrivial views, because 0.4 requires me to create/keep mutable State structs just to create new widgets.)

[tarkah]

Exactly, the old API required you to pass in all of the widget state during view which was such a drag. The new API is so much more enjoyable to work with!