ReSwift is an implementation of redux philosophy in Swift.
If you are unfamiliar with Redux, it is all about managing the state of the application; such that it is always predictable. Let's look at the architecture below to understand it better.
Store - This is where the entire state of the application resides. The state can be just View State or even database state, application state, etc., depending on how you want to use ReSwift. I would recommend using it for view state only because ReSwift executes on the main thread.
View - The View part is the entire view layer or the skin of your application. To put it simply - View is a function of state and at any time it is just a nice representation of the state of your app.
Action - Actions are dispatched by views by means of user interaction, and they are consumed by the store which then updates the state of the app.
There are also a couple of other parts here -
Reducer - Reducers are pure functions. They consume a state, an action and produce a new state.
Middleware - Middlewares are now shown in the diagram above but they act before to the Reducers. Each action has to go through a middleware and it can act on that action. They are very useful for event logging and Action scheduling. If you can think of more cases or would like to discuss a use case of middleware, do post in comments below.
In a normal iOS application, ViewController tends to take more responsibilities than any other component. As the complexity of a screen increases it gets more and more difficult to maintain clean code inside our view controllers. You can relate this to use cases where we end up adding flags and enums to the view controller in order to make it work for different states. Remember the bugs which were very hard to reproduce because only when you do some actions in a particular combination it would surface.
ViewController already comes loaded with lots of responsibilities to handle. Keeping track of flags, enums and view data is the last thing it should worry about.
Imagine how easy it would have been if there was just one method to check, everytime you see a view related bug!
When you use ReSwift, View is just a skin on top of your state. This means at any time if you see something wrong with your view - you can inspect the state to check different values. Also, states can change only by dispatching an action hence you can easily find out what action lead to that state. If it is not very straightforward to predict, you can use middleware to keep a log of all the actions dispatched.
We know of many architectures coming up in iOS e.g. MVVM, MVP, VIPER, etc. ReSwift differentiates itself from these architectures in a very unique way. If you observe closely all the other architectures are focused on separation of responsibility. ReSwift helps you manage the state of your application. This also means that ReSwift can easily co-exist with all these architectures inside the same application.
All view data should be stored in a state. At any point in time – the entire application (as seen by a user) is a “nice representation” of this state.
The state should only be modified by dispatching an action.
For every view controller, only one class (usually a presenter) will listen and respond to state changes.
ReSwift alongside MVP
Below is code snippet from an Image gallery application demonstrating bits and pieces of syntaxes from the ReSwift framework.
For complete code head to https://github.com/amreshkumar/ReSwiftDemo