All about State Management!

Summary of discussions from the BOF Session on state management at ReactFoo Mumbai.

Lately, Twitter has witnessed a spike in debates around Redux — about how it sucks or how good it is. And it would be interesting to know what the developers themselves have to say on this.

Seems like God heard us. Read below to know why.

ReactFoo had its recent edition in Mumbai and developers from different companies attended the event to share their ideas. One of the USPs are Birds of a Feather sessions (BoF).

Birds of a Feather: This idiom is a shortening of the proverb “Birds of a feather flock together.”, meaning that people (birds) of the same kind or interest (of a common feather) enjoy spending time (flocking) together.

It was a bright sunny afternoon and this time we chose State Management in React for the discussion. State Management comes with a broad ecosystem to suit all your needs. But, the thing is: you might not need them at all, or at least yet. So, the main agenda of the talk was to understand them better.

We had Souvik Basu from Tesco and Ankita Goyal from Amdocs moderating the discussion.

They kicked off the discussion with the types of states that we deal with in any web application. Ankita shed some light on these types and spoke about the 5 states. She spoke about them further by describing the five states Data, Control, Communication, Session and location states.

1. Data State

Data state covers information which your application temporarily stores about the big wide world. That is, it covers your business data. Of course, Data doesn’t just magically appear in an application. We need to request it, and then wait until the request succeeds or fails. Here, our Communication State comes in.

2. Communication State

Communication state is the status of any not-yet-complete requests to other services. It helps us in loaders and spinners while we wait for the callback for our HTTP requests.

3. Control State

Control State is state which is specific to a given container component, and which is not stored in the screen’s URL or in the HTML5 History API.

4. Session State

Session state contains information about the user or application which is currently logged In or would want to use it throughout the application. Session state is only ever read when a component is mounted.

5. Location State

Location State is the information stored in the URL bar or HTML5 History API.

We used the most common example to explain it better. We used Netflix to make the picture clear. When browsing Netflix how does it know your last watched episodes or the exact time history to continue the dropped-out movie or episode. Well, It’s the charm of session management. We have other website users v/s Netflix users:

The discussion then shifted to the different ways to maintain these states. We had Redux, MobX, SetState of Vanilla React, GraphQL with Apollo Client. Almost, 90% of the audience had used Redux for the App management.

To start with Redux, we had queries plus experiences shared from the developers. We discussed about the hype Redux has created in the market just because it nicely creates a separation between the data, presentation and controller.

How Redux works and how the store is updated on actions were a part of discussion too. We also had an interesting query: If there are reusable component in a project, then where shall one update the value of the component? On store level or on container-level?

Well the answer to this is — It can be decided by looking at the scope after reviewing the business requirement.

Defining the value at store-level may result the code to be error-prone and may also increase store length. If selectors are unused for reducers, this may lead in the updation of complete state tree and reduces efficiency. Whereas, if they are managed at container levels, then local state and debugging are easier to manage.

We discussed about multiple stores in a redux application, how they are to be handled, and if this complicates the application or simplifies the store management. We had both positive and negative scenarios on the list from the developers’ experiences.

As, Dan Abramov himself stated Don’t use Redux until you have problems with vanilla React and that’s a whole point to understand before diving in React. Redux comes with disadvantages too as free things always come with warnings.

Souvik already discussed about Context API and state management with them were clear and easy for developers to choose based on the application needs.

With Apollo and GraphQL in discussion by the speakers, we asked the developers to share their success stories using these stacks. Well, the usage ratio of Apollo was quite lesser than Redux or MobX. Souvik shared his experience while working with Apollo and GraphQL. We had few queries from the audience about the caching period and the compatibility of them with React for extensive applications.

It was a great conversation between the developers and everyone present thoroughly enjoyed the Session.

Stay tuned for ReactFoo Delhi.