Is it bad to use a different program per "view"?

Learn
1

I’m running my own custom integration. I’m currently using an enum wrapper to manage multiple iced_runtime::Program instances in my app. The main reason for this setup is to avoid having a large single enum for all message types and keeping the logic separated clearly.

Here’s a simplified snippet of how I’ve structured it:

enum GuiState {
    TitleMenu(iced_runtime::program::State<views::title_menu::TitleMenu>),
    SettingsMenu(iced_runtime::program::State<views::settings_menu::SettingsMenu>),
}

enum GuiMessage {
    TitleMenu(<views::title_menu::TitleMenu as Program>::Message),
    SettingsMenu(<views::settings_menu::SettingsMenu as Program>::Message),
}

This is nice because it makes writing the programs themselves very simple. The glue in the enum wrapper can get a bit messy though.

I’m reusing the engine and renderer. The state gets dropped every time there’s a view change.

Can I do something like that or is it considered really bad? Could there be any issues or performance concerns with this approach, or is there a more typical pattern?

Thanks!

2

This is not standard iced. The library provides built-in composability through the .map()ping of the Messages produced by elements and Tasks.

See

For some examples on how to compose your apps.

TL;DR put smaller bits of your app into submodules with their own view and update functions as well as their own Message enums, and use .map() to connect these modules throughout your app.

1 Like