plivesey / RocketData

A caching and consistency solution for immutable models.
https://plivesey.github.io/RocketData
Apache License 2.0
648 stars 50 forks source link

Notifying CollectionDataProvider of updates in a child model #89

Closed dyahns closed 5 years ago

dyahns commented 5 years ago

Here's what I am struggling to get my head around. Suppose we have these models

struct User: Model {
    let id: Int
    let online: Bool
}

struct Message: Model {
   let id: Int
   let user: User
}

and CollectionDataProvider<Message>() in a view controller. AFAIU, Consistency manager only notifies CollectionDataProviderDelegate if CollectionDataProvider has been updated via set setData(). So far, so good.

Now I want my view controller to be notified if User model has been updated from somewhere else. As described here: https://github.com/plivesey/ConsistencyManager-iOS/#how-it-works

There seem to be no method listenForUpdates(self) in Consistency Manager. I presume it was replaced with addListener. But it sounds like I shouldn't use CM directly, because Rocket Data does it for us. The way it is done in my understanding is via DataProvider. Now in the example individual Message models are provided by CollectionDataProvider already. What is the correct approach to listen to User model updates, so that a corresponding Message can be refreshed in the view controller?

  1. Creating a new DataProvider for each Message from the collection?
  2. Creating a DataProvider for User in each Message?
  3. Adding a listener using ConsistencyManager directly?

This scenario is mentioned in Peter's presentation and somewhere else, but I couldn't find a proper example or figure this out. Thanks.

plivesey commented 5 years ago

Hmmm...ok, so I'm not 100% sure I understand the question, but what you want to do should definitely be possible.

You said: 'Consistency manager only notifies CollectionDataProviderDelegate if CollectionDataProvider has been updated via set setData()'. The consistency manager notifies the delegate if the model is updated anywhere. This could happen in a few ways:

  1. You call setData on some other data provider.
  2. You call updateModel or updateModels on the DataModelManager
  3. You call insert or something like this to a collection data provider and the model is updated

In this case, you should get a delegate callback. So, you shouldn't need to do any of those steps to get updates. It should 'just work'. If it's not working for you, could you share some code and I can see if I see some problem with the setup?

plivesey commented 5 years ago

p.s. getting late where I am, so may respond in the morning :D

dyahns commented 5 years ago

Thanks for the reply, Peter. That's right, what I wanted/expected was calling updateModel on a child model to notify CollectionDataProviderDelegate in a same way as calling setData on CollectionDataProvider would. I'll give it another try.

plivesey commented 5 years ago

Yes. Note that if you call setData on data provider A, then the delegate method is not called for data provider A. But it is called for every other data provider which is affected by the change.

plivesey commented 5 years ago

And yes, this includes child models.

dyahns commented 5 years ago

DataModelManager's updateModel() indeed does the trick. I guess this was too easy to not overcomplicate things. Thanks.

plivesey commented 5 years ago

You're welcome. Let me know if you have any questions integrating the library. I'll try to respond quickly :D.

dyahns commented 5 years ago

Thanks for the library. In my experience it has been a joy to migrate to from CoreData-based caching. The documentation is great too, especially in terms of general concepts and setup. What would make it even better is a few use pattern examples or a sample project as people mentioned before. Otherwise it is easy sometimes to fall into overthinking.

plivesey commented 5 years ago

There is a basic sample project in the repo, but it could use a few more complex examples. And it has been a while since I’ve updated the documentation so it’s probably time.

On Thu, Nov 22 2018 at 9:22 PM, < notifications@github.com > wrote:

Thanks for the library. In my experience it has been a joy to migrate to from CoreData-based caching. The documentation is great too, especially in terms of general concepts and setup. What would make it even better is a few use pattern examples or a sample project as people mentioned before. Otherwise it is easy sometimes to fall into overthinking.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub ( https://github.com/plivesey/RocketData/issues/89#issuecomment-441045258 ) , or mute the thread ( https://github.com/notifications/unsubscribe-auth/ABMNTaT-cPDDFnQ94CXhLeBXT1qaaWqiks5uxrNDgaJpZM4YtdMW ).