View Specific Observable Repositories

[mlarandeau]

The VSM docs discuss the use of shared reusable repositories as the recommended means of communicating data and data changes between VSM views. And the sample code steps through this pattern when describing how to implement state models. I fully support this pattern and agree that this should be the recommended approach when needing to share data between views. However, I frequently see views introduce observable repositories that are specific to a that view (i.e. they are not shared).

Introducing an observable repository that is not shared between views can have negative impacts to the view:

1. Adds an additional layer of abstraction with little benefit.
2. Can create a confusing relationship between the repository and the state models where logic that would typically be in the models ends up in the repository and the models are simple wrappers around the repository or the repository is simply a lightweight wrapper around network requests.
3. Repositories are generally implemented as Class types which increases the chances of introducing retain cycles.
4. Encourages sharing state data across view states which in counter to the VSM principles of isolated state data.

So in the context of a view that does not need to share data with other views, I typically build the state models to perform any data loading directly, performs any transformations necessary on that data, and then pass that data onto the next state. Each consecutive state does the same by passing the data directly to the next state. In this scenario, there is no need to observe data changes since the current state is in control of all data changes. I find this ends up being easier to follow since clear connections between states are made and it keeps the state data more isolated. And in situations where there are data actions that need to be shared across different states, leaning on protocol-oriented programming as described here (or other similar protocol-oriented patterns) generally resolves the issue without introducing the complications outlined above.

So the questions I was hoping to discuss here are:

1. Do others agree that generally repositories should be reserved for shared data needs only?
2. Are there examples where a view specific observable repository provides some benefit that can't be reasonably achieved with state models and protocols alone?
3. Should the VSM docs lean heavier on how to implement VSM based views without a repository and introduce the concept of shared observable repositories in the context of "advanced" VSM patterns?

[imtherb91]

I 100% agree. I am guilty of adding an observable repository that is reused but not shared (new instance for each implementation across the app) in the interest of reusing logic but in hindsight this could be done just as well via shared VSM models instead. I would classify shared observable repositories as an "advanced" pattern considering the complexity of stitching together the repository events and the VSM state events + ensuring we aren't introducing any dangerous relationships in terms of reference objects.