How to create a view which conditionally selects the child view to show?

[chriskilding]

Say that I have a parent view and three possible child views as in the example below.

The parent view should conditionally select which child view to show based on the value of self.thing.

The questions are:

1. Where would I put the logic to select the child view?
2. Would I put the logic in the same place if the children were FactoryComponents to be constructed in a list (rather than SimpleComponents)?

enum Thing {
  Foo(x, y),
  Bar(z),
  Baz
}

// relm4 parent view

struct ParentModel {
  let thing: Thing
}

#[relm4::component]
impl SimpleComponent for ParentModel {
  // ...
} 

// relm4 child views

struct FooModel {
  x: i32,
  y: i32,
}

#[relm4::component]
impl SimpleComponent for FooModel {
  // ...
} 

struct BarModel {
  z: i32,
}

#[relm4::component]
impl SimpleComponent for BarModel {
  // ...
} 

struct BazModel {}

#[relm4::component]
impl SimpleComponent for BazModel {
  // ...
} 

[AaronErhardt]

Where would I put the logic to select the child view?

Probably the init() function. If you want to change the widget that is shown dynamically, you can use this syntax in the macro: https://relm4.org/book/stable/component_macro/reference.html#conditional-widgets

Would I put the logic in the same place if the children were FactoryComponents to be constructed in a list (rather than SimpleComponents)?

Yes, that shouldn't change anything regarding the initialization of widgets.

[chriskilding]

I found that the conditional widgets example in the book produced a compile error, so what I had to do instead was extract the match { ... } into its own function, and then call that function inside the view! macro, somewhat like this:

struct ParentModel {
  thing: Thing,

  // must initialise these in the fn init(...) method
  foo: Controller<FooModel>,
  bar: Controller<BarModel>,
  baz: Controller<BazModel>
}

#[relm4::component]
impl SimpleComponent for ParentModel {
    view! {
        gtk::Box {
            append: &self.get_child_widget()
        }
    }
}

impl ParentModel {
     fn get_child_widget(&self) -> gtk::Box {
         let element = match &self.thing {
            Thing::Foo(x, y) => {
                let box = gtk::Box::default();
                box.set_width_request(...);
                box.append(self.foo.widget());
                box
            }
            Thing::Bar(z) => {
                let box = gtk::Box::default();
                box.append(self.bar.widget());
                box
            }
            Thing::Baz => {
                let box = gtk::Box::default();
                box.append(self.baz.widget());
                box
            }
        };

        // optional: apply any common modifications you'd like to apply to the wrapper for all child views
        element.set_hexpand(false);

        element
    }
}

Note that in get_child_widget, because the Foo/Bar/Baz child components are different concrete types, they need to be wrapped in a gtk::Box before being returned from the function to erase their concrete types and make them appear (to the compiler) to be the same thing.

Also note that this is a bit of a work in progress because I haven't tried wiring up those child views to relay messages in/out yet

[AaronErhardt]

I don't understand why the conditional widgets syntax wouldn't work in your case. I is meant for dynamic use-cases though, so it allows for changing the widgets later and not just sets them during initialization.

Note that in get_child_widget, because the Foo/Bar/Baz child components are different concrete types, they need to be wrapped in a gtk::Box before being returned from the function to erase their concrete types

You could just use upcast() instead to cast the type to gtk::Widget.

[chriskilding]

The problem with the conditional widgets syntax, when used with match, is as follows...

If, in the match clause, I attempt to (a) destructure a tuple (like Thing::Foo(x, y)) or a tuple struct (like Thing::Shape { width, height }) and then (b) attempt to use the destructured variables (like x or y) within the widget definition, as shown below:

view! {
        gtk::Box {
            match &self.thing {
                Thing::Foo(x, y) => {    // destructure it
                    gtk::Box {
                        set_width_request: x,      // use the destructured variables
                        set_height_request: y,
                    }
                }
                Thing::Bar(z) => {
                    gtk::Box {
                        // ...
                     }
                 }
                 // ...
             }
       }
}

Then I get the compile error

cannot find value `x` in this scope

---

Notably, if you merely perform the destructuring within the view! macro, but you do not attempt to use the destructured variables, then it will compile fine.

The problem therefore seems to be with the scope / availability of the destructured variables within the view! macro, rather than with the destructuring syntax.

[AaronErhardt]

Sorry for the late reply. Yes, I am actually aware of this behavior and this is a trade-off that was made during the implementation. The way that conditional widgets work currently, everything is initialized. This means that all properties need to be initialized as well and most importunately this initialization needs to be unconditionally. Therefore you can't use variables from destructured fields because Relm4 can't know if they will be available during initialization. Properties with #[watch] and #[track] however will work because they will be updated as soon as their conditional branch is visible and don't need to be initialized upfront.

I hope this makes sense to you and this is also something I hope we will be able to address in future versions of Relm4.

[chriskilding]

Understood - I'll see if I can find another approach for this, perhaps with watch/track as you mentioned.

[chriskilding]

I've added a section to the book about using the track or watch macros for this purpose:

Relm4/book#67