About React *Redux and Funtional Components

Front End Help
#1

Over the years, there have been development overtimes in the React world.

I am very curious if my knowledge is kinda up-to-date. Currently, I have MERN Stack app.

Using

  • Redux
  • class components

I have heard a lot about Context API and it can be replaced Redux. However, many have told me that it is just for a small - mid-size application that can replace redux with Context API. I know that Context API is supported by React.

And, wondering if it has a plan to take over Redux itself? I know that it is not more likely at this time. But, just to be informed.

Moreover, I am working on switching my class components to functional components for the coherency and cleaning up the codes that I have.

Is it a wise decision to spend like 3-4 weeks just to convert perfectly working class components to functional components?

My app is not that big. It is a small-scaled app at the moment. However, I want to organize things right now than when it gets too big to change anything in the end.

I know FB will not cut off the ā€˜classā€™ component, however, functional components with hooks seems way more appealing to me and to understand the code.

Another thing is with the Context API. Even if it does not match up with Redux at the moment, what if it gets better every time and eventually, it can replace Redux at the end?

Just want to hear your thoughts on this topic!

#2

Yes. It can do some of the same things that redux can do, but I think it is only good for small apps. There are a lot of things that redux can do for you that extend beyond simply moving state around.

Is it a wise decision to spend like 3-4 weeks just to convert perfectly working class components to functional components?

It depends - are you getting a benefit out of it? It will make your app a little lighter and a little faster. If youā€™re doing it to learn, thatā€™s fine too.

I know FB will not cut off the ā€˜classā€™ component, however, functional components with hooks seems way more appealing to me and to understand the code.

From FB:

We intend for Hooks to cover all existing use cases for classes, but we will keep supporting class components for the foreseeable future. At Facebook, we have tens of thousands of components written as classes, and we have absolutely no plans to rewrite them. Instead, we are starting to use Hooks in the new code side by side with classes.

I think the point is that while classes will be supported for a (long) while, functional components and hooks are the future.

Another thing is with the Context API. Even if it does not match up with Redux at the moment, what if it gets better every time and eventually, it can replace Redux at the end?

I donā€™t think they will. I think it is just meant for light functionality. React has always tried to be an un-opinionated library. If they start hard coding redux and all the other things redux middleware can do for you into the library, it gets closer to an opinionated framework. I think context is just there if you only need some light data management. But things like redux should be around for a while - there are just so many powerful things it can do - sagas, extracting and reusing logic, etc. And there are so many packages that depend on it.

#3

Itā€™s a primitive, to be built upon. It works totally fine, thereā€™s no need to expand the scope of how it works or what it does. As @kevinSmith says, itā€™s useful for simple things. For very simple usecases it can perform the same job as Redux.

Other examples that encompass an entire app could include auth logic, ie holding the state of whether a user is logged in or out. Or another good example Iā€™ve seen is providing status update models. Each context provider is generally used for a single, simple, discrete thing. Apollo is another example ā€“ you give the provider the code that sets up a GraphQL client, and it provides a cache for optimising the queries you make against it.

But most often itā€™s used at a smaller level than that. For example, to build complex components that have multiple other components nested inside ā€“ say a slider, or a tabbed interface. They are wrapped in a context provider which holds the overall state that the subcomponents can easily access. Many major libraries leverage it this way: Formik and Styled Components for example.

So is still useful for more complex things, but itā€™s used as a primitive to be built upon. The most pertinent example here is React Redux: Context is how React Redux works. So it doesnā€™t quite make sense to say Context will replace Redux. Context works great, thereā€™s no real need to alter how it works now, and using it instead of Redux for complex usecases (which is what Redux is designed to handle) effectively just means writing Redux and React Redux ā€“ thereā€™s not really much point, because itā€™s just replacing one thing with the same thing

2 Likes
#4

Thank you for your answer! Very helpful and full of meaningful words.

#5

Thank you for your answer as well! That is what Iā€™ve been hearing. And wondered if FB wants to take a step forward with the Context API.

I personally prefer Redux over Context even in the small-sized app. But well, both have a different purpose I guess.

#6

Itā€™s not either/or. Context is a necessary tool, there isnā€™t a step forward to make ā€“ itā€™s been part of React for a long time, the ā€œstep forwardā€ was to fix the API for it, which was done. If it was more complex and specific, a clone of Redux, it would be much less useful.

Redux is a library that has a specialised use case ā€“ most apps donā€™t need the added complexity, or may use something different.

Context does not have a specialised use case, itā€™s just part of the React API, it needs to be simple.