Post

Replies

Boosts

Views

Activity

SwiftUI data flow with multiple models that depend on login state
Hi! I’m struggling a bit with data flows in SwiftUI. Most SwiftUI sample apps I’ve seen use one large app model / store and inject that into the environment. That works for small samples, but I’m not sure how this should scale in a real app where the data is naturally split into multiple models/services. For example, I may have separate types for things like: @Observable final class AuthModel { ... } @Observable final class MediaSourcesModel { ... } @Observable final class UsersModel { ... } final class HTTPClient { ... } Some of these only make sense once the user is logged in. For example, media sources, user data, and the HTTP client may all depend on the current user/session/token. What I’m struggling with is where these objects should be owned and created in a SwiftUI app. I’m trying to avoid creating them directly inside a view body, because that can recreate them as the view updates. I’m also unsure whether putting this setup in custom view initializers is the right direction, since SwiftUI views are lightweight and can be reconstructed. What is the recommended ownership / data-flow pattern for this kind of setup? More specifically, how should a SwiftUI app usually handle several separate models that depend on login state, without turning everything into one large global model? Thank you!
Topic: UI Frameworks SubTopic: SwiftUI
1
0
46
3d
SwiftUI data flow with multiple models that depend on login state
Hi! I’m struggling a bit with data flows in SwiftUI. Most SwiftUI sample apps I’ve seen use one large app model / store and inject that into the environment. That works for small samples, but I’m not sure how this should scale in a real app where the data is naturally split into multiple models/services. For example, I may have separate types for things like: @Observable final class AuthModel { ... } @Observable final class MediaSourcesModel { ... } @Observable final class UsersModel { ... } final class HTTPClient { ... } Some of these only make sense once the user is logged in. For example, media sources, user data, and the HTTP client may all depend on the current user/session/token. What I’m struggling with is where these objects should be owned and created in a SwiftUI app. I’m trying to avoid creating them directly inside a view body, because that can recreate them as the view updates. I’m also unsure whether putting this setup in custom view initializers is the right direction, since SwiftUI views are lightweight and can be reconstructed. What is the recommended ownership / data-flow pattern for this kind of setup? More specifically, how should a SwiftUI app usually handle several separate models that depend on login state, without turning everything into one large global model? Thank you!
Topic: UI Frameworks SubTopic: SwiftUI
Replies
1
Boosts
0
Views
46
Activity
3d