Evolving with State Management

October 08, 2019

This is a short story on how I'm evolving with State Management. image

Stage I - React

When I initially started development with React I used to use only react for the state management. Sharing state with child component by passing it as props. That's cool, that's the only way to do it back then.

There were other state management tools like Redux, Flux. Didn't use them. Ask me why ? Because why to use another library when react can do it all alone. πŸ˜‡

I was able to feel the pinch when our application grew bigger. Passing props from component to comoponent was hard to maintain. 😞

Decided to include external state management library

Stage II - React + Redux

We choosed to go with Redux since it had good community support and was used by some popular applications like Airbnb.

Learning redux was bit hard. First I learned only Redux, then I learned how to use redux in react applications. Creating store, reducers, actions, extracting data with mapStateToProps, dispatching Actions with mapDispatchToProps, uff that's a lot to slove the state managemet problem.

But that was totally a worth.

Once I understood it well and became familar with Redux, it was too easy to work with it. Redux thunk to handle asynchronous actions, Redux Form to handle form state was pretty much used in most of my components.

React + Redux was great until I moved to another world.

Stage III - React + Apollo GraphQL Client

I joined an organisation where they have built their entire backend system with GraphQL. I had just tried graphql in a tiny project without any library. They were using Apollo GraphQL Client to talk with GraphQL API. Apollo Client is a state management library, it helps is request only required data from graphql api as a query. It's completely different than how Redux works.

Even before learning it, I was exploring how it is used and how it works within the application. It is magical. It comes with an in-memory cache where it stores all the data which we received from the server. If the same API is called again, it won't make another request to fetch the data from server rather picks it from cache. It can be configured as per our needs and provides other benefits also.

Once you try this, you never feel like going back to redux and REST. 😁

Conclusion : Things keep evolving, we need to adopt them as per our needs. All new things come to solve some kind of problem.