0
227
ViewsHow to think about model/state structure when using ComposableArchitecture?
I'm trying to create a basic time tracking app using SwiftUI and the ComposableArchitecture. But I'm struggling with how I should think about modeling the data structure/app state in a modular way. The app is a time tracking app, so it has: a Project, which can have zero or more Task's, which can have zero or more Activity entries.
Below is a diagram of my current structure.
The problem is that I get is that with this structure is that now ProjectState has two different list of tasks. One through project.tasks, and another through tasks: IdentifiedArrayOf<TaskState>.
How should I think about modeling this?
I don't want to merge data model and the app state, since the app states are more view specific, and might add view specific state, which might differ in different places. The data model is the general model that will be used throughout the app. That's why it might be good to have a relationship between Project->Task->Activity. But the composable architecture app state also needs a similar relationship between it's different states.
1 answers
Answer question0
Ok, so after looking at lot's of the example projects from PointFree, I think I might have had a wrong metal model when looking at this. I think I did wrong in looking at the data model and the app state as two different things, and was looking for a way to sort of synchronise them.
In the end I just accepted that they are the same thing, and moved everything directly to the AppState. This made everything much simpler to reason about, and I could delete a lot of extra code, which might be a hint that this was a good path to take.
But I would still love some feedback if anyone have more input with regards to this. Below is my current structure.
