Consequences Of Redux In Your Application

Pros and cons of using and not using Redux in your React Native application.

Guiding a right way. Photo by Mike Wilson on Unsplash

Before continuing to the next article of implementing Redux in our demo application, it is important to know what are its importance and whether you really need it in your application or not. I will be discussing that in this article.

Redux, being a state management library for an application, is popularly debated in regard of it’s use as important or cumbersome. Each party has its set of needs and requirements which led to this indifferent feeling towards Redux. Let’s see why?

One of the reason Redux is thought as cumbersome is because it asks you to do-certain-things-in-a-certain-way.

It asks you to keep a single store, which saves the application state in plain objects and arrays. And it asks that any changes in the application should be done by pure functions — functions that for the same input will provide same output every time, with no side-effects.

This way led to indirection and boilerplate. A lot of restrictions and boilerplate for using one library, some may think!

And it is thought as important because it separates the concerns.

It does so by implementing a structured flow by separating the logic of saving data into three steps of act[ion], reduce[r] and store.

This way made components simpler and debugging easier. A lot of headaches saved by using one library, some may think!

Analogy

Pedestrian crossing. Photo by Max Bender on Unsplash

Consider this — there is a pedestrian on one side of a highway and you want to make her pass to the other side. Surely you can make her cross the road when the light is red. This way is simple, easier and less time consuming.

But what if the highway is a busy one. Using a signal in that case will create traffic and more people have to wait (people in the vehicle) for getting one job done (making the pedestrian pass). Expensive process, isn’t it?

What you can do to solve this is to make an overhead bridge so that no one has to wait, for getting anything done. Surely this method introduced boilerplate (building a bridge), needed more time for setup, but once it is done there are less worries for the future.

What did this step do? It made a specific path for the pedestrian and vehicles to follow so that they do not interfere with each other. Specifically what it did was, separated the concerns of pedestrian and vehicle.

That is what Redux’s boilerplate does — it separates the concerns.

So do you not need it or not?

It depends.

Generally, if it is a progressive application which has a scope to become a medium or large scale application then chances are you are going to need it.

In a small application you can find that —

1. there are few parent-child relationships, and
2. sharing of data is not widely used among different components

So using local state in those cases is equally fine.

But in a large application keeping the similar structure would bring the following disadvantages —

1. When two components would require a common data you have to move that data to closest ancestor. This can make you keep unintended data in non-related components.
2. Also because of the above reason if you just make an ancestor component for the sole purpose of passing the data, there would be no proper relationship in the application structure.
3. Finally the major disadvantage is that whenever you will face a bug, you will be having a hard time debugging it (let’s leave the fixing on your skills ☺).

So, now you can tell whether you need it or not.

Things to consider

If you decided to use Redux for your application, you might think that you should keep all of your application data in the Redux store — which is not entirely true.

Suppose you have a checkbox in your application. What would you do to check/uncheck the checkbox?

• Call an action → Pass data to reducer → Update store, or
• Just simply keep a local state variable for it

In this case the later seems more appropriate than the former. Similarly you have to consider in your application what you should keep in store and what in state.

Like, you can consider keeping all User Interface (UI) related data and data which is generally less important /not needed in more than one component in local state.

Conclusion

It is up to you how you want to use Redux. Not all highways in your application will be same. Some will be less used while others can be hectic.

You may totally ignore Redux way. Or use it with local state too. Or you can keep all data in store, if you prefer that more!

Let me know if you use it in any more ways? That would be all for now.

Peace!

To read previous article of this series you can follow the below links:
Part1 — Part2 — Part3