[question] store mechanism

[dennisfarandy]

just wondering after watching your presentation in realm, how your mechanism to store your all state? are u using some file storage or core data?

Thanks

[Ben-G]

Thanks for the question!

The state itself only lives in memory and is not stored to disk. I will document an approach on how to use Swift Flow together with a local persistence layer.

The gist is, that you will treat the DB similar to a webservice - as an outside resource that you can query and that can add new data to your in-memory state.

I will leave this issue open until we have added some documentation for this scenario.

[dennisfarandy]

nice! I'm waiting for using it in production then 👍

[juggernate]

Very interested in this. @Ben-G I saw your unidirectional talk on realm.io and also followed the simple tutorial that came later https://realm.io/news/unidirectional-data-flow-in-swift/
Would love to see a similar example of how to do one way flow using ReSwift with Realm for state persistence.

[camel113]

@juggernate +1

[dustintownsend]

@Ben-G is there any update on this? Where you able to create any documentation?

I started moving one of our newer smallish projects to ReSwift after seeing your talk from Realm. I got all the current viewcontrollers moved over and the router set-up as well. I also recently read the unidirectional data flow in swift tutorial from Realm that shows a simple implementation of using Realm as store.

It gave me the idea of a possible ReSwift and Realm integration. I'm curious what you think about this.
Here are some of my thoughts on this:

• The store would mostly be Realm. Use Realm notifications to push changes to subscribers. Maybe have a RealmStoreSubscriber protocol? Or maybe a RealmStore class that could manage the NotificationTokens/subscriptions?
• I think Reducers could be eliminated, since I believe that Realm could handle this. I maybe mistaking on this, but if Realm was able to handle them it could reduce a lot of boilerplate code.
• Actions would just make calls to Realm. So, they would be functions instead of properties like in most of the ReSwift examples. I'm not sure if this would be acceptable.
• It seems over all that Realm fits nicely into ReSwift or at-least Unidirectional State/Data Flow.

I think the main benefits of this would be eliminating the need to code reducers and getting local persistence for free. Also, I think using Realm Results as state would be interesting.

I had some other ideas as well. Like what you said treat the local persistence (Realm in my case) like a web service. For cases where we need to sync a lot of data I was thinking the service that does the syncing could update the Realm directly and the Realm could send notifications to update the state, but if the state is also trying to update the Realm there might be an issue there.

[Ben-G]

@dustintownsend Someone asked a very similar question in #110 - so I would suggest moving the discussion there for now as we have a nice clean slate to discuss how db persistence should work with ReSwift.

Regarding your points:

• The store would mostly be Realm. Use Realm notifications to push changes to subscribers. Maybe have a RealmStoreSubscriber protocol? Or maybe a RealmStore class that could manage the NotificationTokens/subscriptions?
• I think Reducers could be eliminated, since I believe that Realm could handle this. I maybe mistaking on this, but if Realm was able to handle them it could reduce a lot of boilerplate code.
• Actions would just make calls to Realm. So, they would be functions instead of properties like in most of the ReSwift examples. I'm not sure if this would be acceptable.
• It seems over all that Realm fits nicely into ReSwift or at-least Unidirectional State/Data Flow.

Using a database as the core of your architecture instead of stores & reducers is a vastly different approach from the on that ReSwift is taking. Therefore this idea is a little outside of the scope of this repo.

The main idea of ReSwift is to have the entire app state in memory. This includes view state and other temporary state that will not be persisted to disk. This is only possible because in memory reads/writes are really fast. Accomplishing this with a file system db is impractical (you also would not want to store the view state in your db).

ReSwift itself really only provides a state management & propagation mechanism. Persistence can be implemented in many different ways.

Will continue this discussion in #110.