Organization of various states in the program

[aadityadhruv]

I'm currently building an application to learn iced and advance my knowledge of rust. Right now, my program is structured such that I have a root struct which stores the states of everything, as such:

pub struct Process {
...//Some other stuff
currentScreen : ScreenStruct //See below
state : StateStruct,
... //more stuff

}

Currently I have 3 "screens" which I switch the ScreenStruct field in Process, and the view changes based on that field since I have a match statement for that.

I also have a bunch of text input boxes in one of the screens, and for each of those text inputs I need to add an Message enum and a state to store the value of the text input.

This is making my state struct grow large. I also don't know if the match statement in the view method is the correct way to handle different screens.

Any advice on solving these issues would be appreciated!

[CelebrateVC]

Hi @aadityadhruv !

I'm coming here for a similar issue, going off the doc's example of a mulit-view app, the tour it has General navigation messages in 1 Enum with a variant dedicated to "StepMessages", defined later

iced/examples/tour/src/main.rs

Lines 99 to 104 in 817f728

	#[derive(Debug, Clone)]
	pub enum Message {
	BackPressed,
	NextPressed,
	StepMessage(StepMessage),
	}

...

iced/examples/tour/src/main.rs

Lines 213 to 228 in 817f728

	#[derive(Debug, Clone)]
	pub enum StepMessage {
	SliderChanged(u8),
	LayoutChanged(Layout),
	SpacingChanged(u16),
	TextSizeChanged(u16),
	TextColorChanged(Color),
	LanguageSelected(Language),
	ImageWidthChanged(u16),
	ImageUseNearestToggled(bool),
	InputChanged(String),
	ToggleSecureInput(bool),
	ToggleTextInputIcon(bool),
	DebugToggled(bool),
	TogglerChanged(bool),
	}

and then a pile of if let STEP1 = self nested inside of a match

iced/examples/tour/src/main.rs

Lines 231 to 243 in 817f728

	fn update(&mut self, msg: StepMessage, debug: &mut bool) {
	match msg {
	StepMessage::DebugToggled(value) => {
	if let Step::Debugger = self {
	*debug = value;
	}
	}
	StepMessage::LanguageSelected(language) => {
	if let Step::Radio { selection } = self {
	*selection = Some(language);
	}
	}
	StepMessage::SliderChanged(new_value) => {

This approach (or better yet making a new enum for each state, injected as a variant of the StepMessages which is itself in Message) is sustainable for medium scale projects.

From what I have been able to make out there is no way of making Invalid States Unrepresentable with StateMachines and Transitions (because trait Application has fn update(&mut self, message: Self::Message) -> Command<Self::Message> it doesn't let you transition between different states of a state machine over a generic <T> and so you have to cover for all states+messages even if they are not valid. An explicit catch-all panic!() sweeps those under the rug to become a runtime error if they ever come up

It would be nice to have a way to define messages per state, but that's not able to be done at the moment. Below is a snip of my current match on my pet project.