In many of the Iced projects i’ve looked at, i see that things like Database and Web clients are stored outside the Iced application, in a static const (global?), rather than in state passed around by the Application. Is that the common case / best practice? Are there other patterns to consider for accessing a data layer in the application? In mobile development, we often use the Singleton pattern (very similar to this). In that pattern, it tends to be a bit more testable, since the singleton class can be tested independently & often there is a way to inject a mock. Thoughts on application design when it comes to data layers in Iced?
Why not storing it in the struct that implements Application? You can read it in the view and mutably access it in the update functions.
Regarding web clients: I’d make them a subscription and use channels to communicate with them to avoid blocking the UI.
thanks for the reply. I’ve spent the last week or so exploring different patterns, including the ones you mention. I think the main ah-ha moment for me was the “interior mutability” pattern of putting a struct (eg. DataManager) as a field on the impl Application (eg MyApp), which in turn owns some bit of global mutable state (I’m using Arc<RwLock<MyInternalState>>. I saw that this is how some of the http client libraries work, so that you can just clone the outer struct all day long, and it will pass into things like the Command::perform async blocks, cloning the internal Arc in the process. I’ll try to find time to publish some of my example codes, so others can see.
For me using channels to call into a HttpClient library felt heavier than simply calling methods on my “Controller” struct that owned a client. But I agree for messages coming out of the Http, for example if you have a web socket returning values in a streaming fashion.