Divide Iced app code into separate modules and files for State, Message, Update, and View

[lucatrv]

First of all thank you for developing this awesome project, a good Rust GUI library was what I missed the most, finally I found one that I really like!

I would like to propose a suggested crate layout for Iced apps, which further enforces separation of the four Iced fundamental entities state / message / update / view, by splitting them into different modules and files. I find this way much more practical to implement non-trivial Iced apps, because instead of scrolling a single long file I just swap between tabs of my code editor to update the four entities as needed.

Of course anyone can come up to this crate layout autonomously by applying basic Rust programming best practices, but IMHO it would be useful to many people addressing Iced for the first time to get an example coded with separate modules, at least to pop the idea into their mind and better consider how to structure their next Iced project.

Here is my sample implementation, which maybe could be further improved, and I could PR among the Iced examples if you agree:

main.rs

mod iced_message;
mod iced_state;
mod iced_update;
mod iced_view;

use crate::iced_message::Message;
use crate::iced_state::State;
use crate::iced_update::update;
use crate::iced_view::view;

use iced::{Element, Sandbox, Settings, Theme};

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

#[derive(Debug, Default)]
struct HelloWorld {
    state: State,
}

impl Sandbox for HelloWorld {
    type Message = Message;

    fn new() -> Self {
        Self::default()
    }

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

    fn update(&mut self, message: Message) {
        update(&mut self.state, message)
    }

    fn view(&self) -> Element<Message> {
        view(&self.state)
    }

    fn theme(&self) -> Theme {
        self.state.theme.clone()
    }
}

iced_state.rs

use iced::Theme;

#[derive(Debug)]
pub struct State {
    pub text_size: u16,
    pub theme: Theme,
}

impl Default for State {
    fn default() -> Self {
        Self {
            text_size: 100,
            theme: Theme::default(),
        }
    }
}

iced_message.rs

#[derive(Debug, PartialEq, Eq, Clone, Copy)]
pub enum ThemeType {
    Light,
    Dark,
}

#[derive(Debug, Clone)]
pub enum Message {
    ThemeChanged(ThemeType),
    IncrementTextSizePressed,
    DecrementTextSizePressed,
}

iced_update.rs

use crate::iced_message::{Message, ThemeType};
use crate::iced_state::State;

use iced::Theme;

pub fn update(state: &mut State, message: Message) {
    let size_change = 10;
    match message {
        Message::ThemeChanged(theme) => {
            state.theme = match theme {
                ThemeType::Light => Theme::Light,
                ThemeType::Dark => Theme::Dark,
            }
        }
        Message::IncrementTextSizePressed => {
            if state.text_size <= 200 - size_change {
                state.text_size += size_change;
            }
        }
        Message::DecrementTextSizePressed => {
            if state.text_size >= size_change {
                state.text_size -= size_change;
            }
        }
    }
}

iced_view.rs

use crate::iced_message::{Message, ThemeType};
use crate::iced_state::State;

use iced::widget::{
    button, column, horizontal_rule, horizontal_space, radio, row, text, vertical_space,
};
use iced::{Alignment, Element, Length, Theme};

pub fn view(state: &State) -> Element<Message> {
    let choose_theme = [ThemeType::Light, ThemeType::Dark].into_iter().fold(
        column![text("Choose a theme:")].spacing(10),
        |column, theme| {
            column.push(radio(
                format!("{:?}", theme),
                theme,
                Some(match state.theme {
                    Theme::Light => ThemeType::Light,
                    Theme::Dark => ThemeType::Dark,
                    _ => panic!(),
                }),
                Message::ThemeChanged,
            ))
        },
    );

    column![
        row![choose_theme, horizontal_space(Length::Fill)],
        horizontal_rule(20),
        vertical_space(Length::Fill),
        text("Hello, world!").size(state.text_size),
        vertical_space(Length::Fill),
        row![
            button("Increment Text Size").on_press(Message::IncrementTextSizePressed),
            button("Decrement Text Size").on_press(Message::DecrementTextSizePressed),
        ]
        .spacing(20)
    ]
    .spacing(20)
    .padding(20)
    .align_items(Alignment::Center)
    .into()
}

[13r0ck]

The Elm architechture generally has long files, that is intentional. ( See 1 & 2 ).

Because of that I dont see your requested change happening to iced. I would also recommend you try the longer file method typical of the elm architechture, but if you decide not to, there is no reason that you cant have your impl Application functions just be functions that call helper functions that you store in your separate files 😃.

[hecrj]

The "Culture Shock" section of the Elm guide warns against this:

Some folks see The Elm Architecture and have the intuition to divide their code into separate modules for Model, Update, and View. Do not do this!

It leads to unclear and debatable boundaries. What happens when Post.estimatedReadTime is used in both the update and view functions? Totally reasonable, but it does not clearly belong to one or the other. Maybe you need a Utils module? Maybe it actually is a controller kind of thing? The resulting code tends to be hard to navigate because placing each function is now an ontological question, and all of your colleagues have different theories. What is an estimatedReadTime really? What is its essence? Estimation? What would Richard think is its essence? Time?

If you build each module around a type, you rarely run into these kinds of questions. You have a Page.Home module that contains your Model, update, and view. You write helper functions. You add a Post type eventually. You add an estimatedReadTime function. Maybe someday there are a bunch of helpers about that Post type, and maybe it is worth splitting into its own module. With this convention, you end up spending a lot less time considering and reconsidering module boundaries. I find that the code also comes out much clearer.

State, messages, update, and view logic are all tightly coupled together and part of the same abstraction. Every module in Rust is like a small library. It makes no sense to have a module that only exposes an incomplete abstraction!

[lucatrv]

Thanks for your prompt replies and inspirational references, I'll reconsider all this myself.
Please feel free to close this issue or keep it open for further discussion as you will.