Question: How do you manage the cases where there are several views / view models that need to access the information of one repository? Do you use a shared instance of that repo?
That's exactly right, usually you'd want to have a shared instance of the repo and dependency-inject it to all the view models which use it.
So often-times your app might have a few semi-global repositories such as User Info, depending on which models might be shared between lots of your app.
One thing to bear in mind though - this means all your subscribers across view models will be broadcast to if you publish a new updated value.
I'm thinking about using this approach but removing the view model altogether.
Here is the reasoning:
* I could use the publisher receiver on the SwiftUI views directly
* Then I could use 1 environment object for each Repository (and avoid the static shared properties)
* Moving all the @Published properties in the view models to the SwiftUI views as @State will end up in less redraws of the views
* I also like to have 1 less layer
---
I still have to do some experiments with it and see if I can achieve the same level of unit testing over the @State properties as I could with the @Published properties. It might be tricky if I use `private` for all those properties, but I'll try.
---
Another thing I like is to use 2 SPM packages for each "feature". So for example, if I have a Calendars feature, I'd create CalendarsUI and CalendarsData.
* On CalendarsData I can define all the API models as internal and all the UI models as public. Then make the repository public and publish UI models.
* On CalendarsUI I just import the CalendarsData module, and I can't even access the API models.
Question: How do you manage the cases where there are several views / view models that need to access the information of one repository? Do you use a shared instance of that repo?
That's exactly right, usually you'd want to have a shared instance of the repo and dependency-inject it to all the view models which use it.
So often-times your app might have a few semi-global repositories such as User Info, depending on which models might be shared between lots of your app.
One thing to bear in mind though - this means all your subscribers across view models will be broadcast to if you publish a new updated value.
I'm thinking about using this approach but removing the view model altogether.
Here is the reasoning:
* I could use the publisher receiver on the SwiftUI views directly
* Then I could use 1 environment object for each Repository (and avoid the static shared properties)
* Moving all the @Published properties in the view models to the SwiftUI views as @State will end up in less redraws of the views
* I also like to have 1 less layer
---
I still have to do some experiments with it and see if I can achieve the same level of unit testing over the @State properties as I could with the @Published properties. It might be tricky if I use `private` for all those properties, but I'll try.
---
Another thing I like is to use 2 SPM packages for each "feature". So for example, if I have a Calendars feature, I'd create CalendarsUI and CalendarsData.
* On CalendarsData I can define all the API models as internal and all the UI models as public. Then make the repository public and publish UI models.
* On CalendarsUI I just import the CalendarsData module, and I can't even access the API models.
---
Thanks for your response!