Programming Architectures — Redux | ReSwift (part 0)
- The introduction of Redux | ReSwift
Updated on 10th April 2019, 8:21 AM GMT 5:30+
Welcome to the new article series about Redux | ReSwift, the latest programming architecture and hottest libraries for front-end development.
Have you heard about Redux before?
- If the answer is Yes, That’s great. This article is for you to gain more knowledge.
- If the answer is No, Don’t worry. You will learn in-depth about Redux | ReSwift starting from
- Introduction
- What was the problem? Why redux introduced?
- How it solves the problem?
- Why do you need to use Redux?
- Practical use of Redux | ReSwift with tutorials
Introduction:
Redux is the latest programming architecture introduced by Dan Abramov and Andrew Clark , pre-released in June 2015. It was inspired by Facebook’s Flux and functional programming language Elm. Redux is a predictable state container, a data-flow architecture for JavaScript apps.
Javascript? yes, JavaScript.
You are here to learn about Swift, Right? don’t worry we will morph to Swift, this is just the background of Redux.
Redux written in Javascript, ReSwift is the Swift implementation of Redux by Benjamin Encz. In “The introduction of Redux | ReSwift” article I will use words Redux and ReSwift interchangeably.
What was the Problem? Why redux introduced?
Think about the Facebook app, it shows unread notification count in notification icon, badge value of the mobile application and in the title of a browser tab.
Notification count depends on many actions, e.g. someone like your post, comment on your post, send you a friend request, tag you in some posts or photos and many other actions. In the past days, it was hard to manage accurate unread count for Facebook, sometimes it was showing wrong count value.
The input sources of the unread count value are many actions, also needs to update many places with the exact same value of unread count. So this is a logically many-to-many relationship between actions and views and many-to-many relationship always hard to manage.
Redux is introduced to solve this problem in a more simpler way using application state management.
How Redux solves the many-to-many relationship problem?
- Redux maintains the state of an entire application in a single immutable state, stored in a single entity that can’t be changed directly.
- Views those are dependent on that entity will subscribe for the updates.
- When some actions triggered, a new entity is created and will be broadcast to subscribers.
This is a clean and easy solution to understand and implement.
Why do you need to use Redux?
Let’s first understand the core concept of this architecture before start using it. If your app required to manage multiple states and needs to update data to multiple screens at the same time as described above, redux is more suitable architecture for your needs.
Example,
Suppose you are developing a Ride Booking Application, where a rider is allowed to book a ride.
In this scenario, Ride has multiple states like [requested, approved, rejected, started, cancelledByDriver, cancelledByRider, completed, paid]
.
requested
: Rider send the new ride requestapproved
: Ride request accepted by Driverrejected
: Ride request rejected by Driverstarted
: Driver pick up the rider from the pickup locationcancelledByDriver
: Driver cancel the ongoing ridecancelledByRider
: Rider cancel the ongoing ridecompleted
: Driver drop the rider to the destination locationpaid
: Rider pay the total bill of the ride
Here, few states of the ride can be changed by Rider while few of them can be changed by Driver actions.
When ride state changed, suppose we need to update admin panel and mobile app of driver and rider both for related state changes. Also, consider that we have two possible ways to update the mobile app via Push notifications and Socket updates.
After thinking about this scenario, once you start coding the result will complex code with too many [if — else if — else] conditions and switch statements. The resulted code will become hard to read, hard to understand, hard to debug and hard to test. We can reduce the complexity of code by using Redux architecture in this scenario.
Benefits of Redux:
- More Readable and understandable code
- Predictable behaviors of the whole app
- Consistency of code
- Scalable code when requirements changes
- The testable code in test-drive-development
- Functional Programming
- Centralize application state management
Don’t directly start using the redux implementation before understanding the architecture and problems it is solving.
@hitendrahckr is typing
Stay tuned, More parts coming soon with example tutorials…
Liked this article?
Give claps and show your support. It doesn’t cost you anything to clap.
Where to go from here?
Be my patron — request for any topic and sponsor future articles
More parts coming soon of this series…