Passing global state (e.g. app preferences) to components

[chriskilding]

Occasionally I have a need to share a variable with a lot of components within the app. (Not document state which I've mentioned before; I mean more like app preferences variables.)

I'm aware of the example which uses a static global SharedState instance to share this kind of information. However a static global variable impacts the testability of components, so I'm wondering whether there is a better way.

In SwiftUI there is a concept of an @EnvironmentObject - an object that's placed into the app's global environment. (Tutorial available at https://www.avanderlee.com/swiftui/environmentobject/). This design is neat in that it lets you achieve the deduplication of code, while retaining testability (just insert a mock of the environment object when you instantiate the SwiftUI view in tests, i.e. MyView().environmentObject(mock)).

Could we somehow translate this into Relm4? Perhaps something like this...

struct AppEnvironment {
    // app-global state
    sensitive: bool,
}

struct App {
    // any view-local state, as normal
}

#[relm4::component(pub)]
impl SimpleComponent for App {

    type Environment = AppEnvironment;

    view! {
        #[root]
        gtk::Box {
            // embeds Foo (and many other components)
        }
    }
}

struct Foo {
    // any view-local state
}

enum FooInput {
    DoSomething,
}

#[relm4::component(pub)]
impl SimpleComponent for Foo {

    type Input = FooInput;
    type Environment = AppEnvironment; // perhaps we could get this from the parent component? (to avoid duplication)
    // ...

    view! {
        #[root]
        gtk::Button {
            set_label: "Do something",

            #[watch]
            set_sensitive: self.environment().sensitive,
        }
    }
}

[chriskilding]

Thinking about this some more, we probably don't want to share the common variables directly, because this goes against the grain of the CSP-style communication between components that normally happens.

Instead, we want the ability to send events about the common variables to all components. Something like this...

enum MyEnvironmentInput {
    Sensitive,
    NotSensitive,
}

struct App {
    // any view-local state, as normal
}

enum AppInput {
    // events specific to App
}

#[relm4::component(pub)]
impl SimpleComponent for App {

    type Input = AppInput;
    type EnvironmentInput = MyEnvironmentInput;

    view! {
        #[root]
        gtk::Box {
            // embeds Foo (and many other components)
        }
    }

    fn update(&mut self, message: Self::Input, sender: ComponentSender<Self>) {
        // process AppInput messages as usual
    }

    fn update_environment(&mut self, message: Self::EnvironmentInput, sender: ComponentSender<Self>) {
        // process EnvironmentInput messages
    }
}

struct Foo {
    sensitive: bool,
    // plus any view-local state
}

enum FooInput {
    DoSomething,
}

#[relm4::component(pub)]
impl SimpleComponent for Foo {

    type Input = FooInput;
    type EnvironmentInput = MyEnvironmentInput;

    view! {
        #[root]
        gtk::Button {
            set_label: "Do something",

            #[watch]
            set_sensitive: model.sensitive,

            connect_clicked => FooInput::DoSomething,
        }
    }

    fn update(&mut self, message: Self::Input, sender: ComponentSender<Self>) {
        // process FooInput messages as usual
        match message {
            FooInput::DoSomething => {}
        }
    }

    fn update_environment(&mut self, message: Self::EnvironmentInput, sender: ComponentSender<Self>) {
        // process EnvironmentInput messages
        match message {
            MyEnvironmentInput::Sensitive => {},
            MyEnvironmentInput::NotSensitive => {},
        }
    }
}

[AaronErhardt]

This looks a bit like what Reducer does, or am I wrong?

I didn't have a lot of time to work on Relm4 recently, but I've been thinking about creating a new library with Relm4 as starting point that would use a quite different yet similar approach. I think this would also solve/improve a lot of your use-cases.

The general idea is the following:

1. You define your entire app state in a single struct (with several nested structs for larger apps)
2. You define different types of messages and specify how they modify the state and also their scope (more about that later)
3. You define parts of the UI (with different scopes) and put them together
4. UI updates work through properties (special Rust structs):
   1. Property bindings sync state between state and UI directly
   2. Code can be specified to watch for property changes and update the UI accondingly

About "scopes":
For example, you don't need access to the global state everywhere, but just state.login_form, so "/login_form" would be your "scope", a subset of the global state.

enum AppMsg {
    Increment,
    Decrement
}

struct State {
    counter: CounterState,
}

struct CounterState {
    // Here we define a property
    value: Prop<u8>,
}

#[ui_root]
impl AppRootUi for AppUi {
    view! {
        gtk::Window {
            set_title: Some("Simple app"),
            set_default_size: (300, 100),

            gtk::Box {
                set_orientation: gtk::Orientation::Vertical,
                set_spacing: 5,
                set_margin_all: 5,

                gtk::Button {
                    set_label: "Increment",
                    connect_clicked => Msg::Increment,
                },

                gtk::Button {
                    set_label: "Decrement",
                    connect_clicked => Msg::Decrement,
                },

                #[name = "my_label"]
                gtk::Label {
                    // 1. Solution for view updates
                    #[watch("/counter/value")]
                    set_label: &format!("Counter: {}", value),
                    set_margin_all: 5,
                }
            }
        }
    }

    // 2. Solution for view updates
    #[update_handler("/counter/value")]
    fn update(widgets: Self::Widgets, value: &u8) {
        widgets.my_label.set_label: &format!("Counter: {}", value),
    }
} 

fn main() {
    let app: App<State> = App::new();

    // We only get access to `CounterState` because
    // global state isn't needed here.
    // (Multiple scopes would also be possible, I think)
    #[scope("/counter")
    app.add_handler::<AppMsg>(|msg, state: &mut CounterState| {
        match msg {
            AppMsg::Increment => state.value += 1,
            AppMsg::Decrement => state.value -= 1,
    });
}

The general idea is to separate the functionality of components into logical units. You can take care of state management and UI updates in entirely separate parts of the code and only define scopes as you need them. This also makes it much easier to share global information (maybe with multiple scopes even). You could even add multiple overlapping message handlers and multiple overlapping UI parts as well.

Just an idea so far, but I think at least the general concept should work well in Rust code. I think this would also solve the "Environment" stuff, albeit with scopes of global state instead.

[chriskilding]

One thing I'd very much caution against is defining the scopes as string paths. This is because the app developer must then deal with connascence of strings, i.e. ensuring the scope path elements always match component names. This phenomenon makes automatic refactoring more difficult (because unlike normal code symbols, the compiler and IDE cannot automatically/reliably refactor strings).

It also makes it harder to debug 'unexpected silence' problems, i.e. when you're expecting messages to be received by a component but they're not coming through (because the string path was subtly incorrect).

[chriskilding]

On the point of using Prop<...> for component variables - I see this as quite a departure from the Elm way of doing things (where messages update local vars within the component, which are just regular vars - not wrappers). There's nothing wrong with that of course if it's intentional - but note that this pushes your concept framework much more in the direction of how SwiftUI does things (where mutable view variables use a property wrapper like @State / @Binding / @EnvironmentObject - they're not just plain variables), and therefore perhaps that should be reflected in the wider design of the concept framework.