3 ms·
struct Counter { // The counter value value: i32, // The local state of the two buttons increment_button: button::State, decrement_button:
by andrekandre 5y ago
struct Counter {
// The counter value
value: i32,
// The local state of the two buttons
increment_button: button::State,
decrement_button: button::State,
}
impl Counter {
pub fn view(&mut self) -> Column<Message> {
...
}
}
this looks like it holds state in the ui layer... wouldn't it be better to keep state in some separate state/model object (struct) and bind the ui to that instead?
not doing it this way couples a lot of logic/state to the ui framework which means its much harder to switch ui frameworks later, not to mention testing the logic independently of the ui choice...
- andrekandre 5y agoto whoever downvoted, instead of downvoting, maybe its better to make a counter argument? im asking because i hope to get some insight not a silent downvote
- ensiferum 5y agoI agree with your point. In fact it's the approach I'm doing myself in my current UI lib (which has a very specific use case but the point still applies). https://github.com/ensisoft/gamestudio/blob/master/uikit/window.h https://github.com/ensisoft/gamestudio/blob/master/uikit/win...
- andrekandre 5y agothats a cool game engine!
- thurn 5y agoThis type of state is typically used for "interface state", e.g. "is this toggled open", "which menu item is selected", etc. It's definitely normal to combine that with a 'database' style model layer, as you say.
- cdaringe 5y agoAgreed. This is not like elm at all. This is much more like react pre v14