Take 3, Scene 13: Redux Your React

On this episode of Take 3, we take a look at the React development library and how it pairs with the Flux pattern Redux. Vlad Zelinschi and Cassian Lup join us all the way from Romania to discuss the multiple uses of this library and why it’s taking over the development space.

Episode Highlights

  • Vlad and Cassian give some background on the React library and share why and how it’s different from other libraries of the same nature
  • We discuss the reason why big companies like Facebook rely on React and whether or not more companies will begin using this library
  • Vlad delves into the interaction between React and Redux, and shares what makes these two such a successful pairing

About the Guests

Vlad Zelinschi is a UI Technical Lead and a part of the ATG Team at 3Pillar Global. He has a strong passion for new technologies and clean, simple code.

Cassian Lup is a Module Lead at 3Pillar Global who has a passion for web technologies. He has worked with various platforms and libraries, including React and Angular.

Read the Transcription

Julia Slattery: So let’s start with the basics. What is React and how does it differ from other component libraries?

Vlad Zelinschi: React is actually an open-source JavaScript Library that started inside Facebook roughly around 2011 and was first open-sourced in May 2013, I think. Since then it has gained a lot of traction. React inspires and makes it simple to build complex web applications because of its simplicity. Because of its clear API, it is very fast. And I am talking about virtual DOM implementation here. It has a data flow that is very specific and well-defined inside the application and, in my opinion, also a very mild learning curve.

Cassian Lup: Yeah I couldn’t agree more with Vlad. From what I can remember, I started actually working with Angular at first, you know, out of the big, well-known libraries in JavaScript. Well actually, Angular is a framework and we will get to that later I guess. But React has lots in the library and to what Vlad just said. It took me about two weeks to get familiar with the ways of doing React as compared to a lot more time with Angular. So I would start there. It is definitely more accessible to the developer. It is easier to get into it. Also I would say that it’s more related to the V in MVC (Model View Controller). The paradigm that would have been accustomed to in the programming world for so many years now.

We have the V, the View, and React has a lot to do with that. As I was saying before, it is not a framework. Although, it is probably incorrectly being labeled as one by some. But despite that, it is often compared to AngularJS. So as Vlad said, it does provide ways of building fast and preferred UIs, which is definitely something that I noticed right off the bat. You just have this crazy optimized experience and performance, and that is an issue in web development.

Julia Slattery: You mentioned Facebook there – this is a library that has been used by a lot of big companies, such as Facebook. What kind of value does it bring to the table?

Vlad Zelinschi: I think React was thought to be for easy adoption for the first line of code. First of all, it’s very declarative in nature and this allows developers to better focus on describing how they want their screens to look rather than the process of getting there. React just takes a set of data – basically your application state – and based on that set of data, it is going to run the UI. Another bonus is that React does this whole re-render thing with great speed. This is because of the virtual DOM underlying implementation and all of the performance improvements that the library does under the hood. Like, for example, it knows how to batch dates.

I think it also conveys a lot of familiarity, because writing stuff in React looks a lot like writing plain old HTML. This is due to the JSX syntax. I remember that this was a strong point against React in the beginning – why brain developers complained, why bringing HTML and JS is a good idea. But it seems that the community got used to this after all and they are all now wholeheartedly embracing this. The API is very simple. All you need to know to write React applications are a couple of component lifecycle hooks and you need to be aware of what you can do inside each and every one of them. But I think that one of the biggest losses that React brings on the table is related to the data flow inside the application.

React itself, and later the combination of React and Flux or Redux for example, is heavily inspired by the Elm architecture. This provides a very simple model of updating portions of UI. It also allows for great modularity, which this becomes perfect when you want to scale out applications. So complex applications become a breeze. The whole model view of data is split in React between the library itself and maybe other pairings like Flux or Redux, but the data flow model is based on the same principles as an out. The components in React are hierarchal in nature and they are based on simple inheritance principles where child components, for example, can access parent information if it is being fastened.

All of this makes it easy for developers to reason about how the data flows inside the application. Which in turn eliminates a lot of issues because as Cassi said, we always say state and state changes are like the root of all evil in front-end.

Cassian Lup: Yeah, they are definitely evil, I can say that as well. So you mentioned Facebook, you asked why did they come up with this. I have done. As far as you can learn about Facebook, from what I know, they actually started using MySQL at the beginning and then they actually tweaked it to their hearts desire. They tweaked it very heavily so that it could answer to their own necessities as a business and would just be able to handle all of that traffic. I can see that in React as well. They built it to be agnostic to architecture and that is probably their way of thinking about software.

They want to have it very modularized and able to handle one thing and handle it well. So that’s how I see React: it does one thing and it does it really well. We were talking about what differentiates it from one thing or other libraries or frameworks and the world of UI. One thing that we can see with it is it is component-based. You write in what Vlad mentioned earlier the JSX language. You actually can create HTML that looks like HTML. In fact, it is not really HTML. But you create your component and write it in this language that feels natural. You write it right there in the JavaScript code, which is another new thing. And I cannot emphasize enough how big of a deal it is to be working with components as state machines.

We know like routers as state machines. The new UI router in Angular is one example and it is just done a great job of handling routes. So we see components and components-based architecture as being the way forward in UI. And another big topic that has been found in a lot of blog posts in recent times in the UI world is Data Bindin. What React comes and pushes is the single Data Binding model, if you are to compare it to Angular. Let’s say which Angular one came and imposed or put out of the box the double Data Binding model, your watchers, your information, your inputs were being watched all the time for changes.

That put a dent into performance. Whereas React comes and just says, you know, data is to flow from one end to the other and not the other way around. Which simplifies the whole process. So React heavily bases its way of rendering the UI and handling events by this philosophy of single data binding. So these are a few items that really put it aside and make it stand out from the crowd.

Julia Slattery: You mentioned Redux a little bit there, Vlad, and you recently held some workshops and gave talks on the pairing of React and Redux. Could you give us some background on Redux?

Vlad Zelinschi: Yes, of course. Redux was created by a guy named Dan Abramov. Dan is a very smart guy who now works with Facebook and he is one of the developers that are constantly helping and supporting the community with basically anything that is related to the React-Redux ecosystem. As Dan puts it, Redux is nothing more than a predictable state container for JavaScript applications. So right from the, let’s say formal definition, I would like to point something out. Namely that Redux is not something tied to React. It is more of a pattern that can actually be applied and paired with any other framework or library that you may want to use.

Though indeed it makes much more sense to pair it with some than others, this pattern is basically a Flux simplification. So it has its origins in the Flux library that Facebook created. When Facebook released Flux, a lot of people complained about it and a lot of people said that it was unnecessarily complicated. So naturally, multiple variations of this pattern spawned inside the JavaScript community, though I would say that Redux is definitely the most successful and popular of them all. And it also started you to the fact that Dan needed to have something similar to do time travel debugging inside his JavaScript applications, which is something that is very hard to implement.

Basically, he wanted to see how the state inside the application mutates over time and to be able to go back at any point he wanted. So that is how the need for Redux emerged and that is why he created Redux, which makes all these things like time travel debugging easy to achieve because of the way it is built under the hood and because of the functional programing concepts that Redux embraces.

Julia Slattery: How do those two work together, and why is it such a successful pairing?

Vlad Zelinschi: So basically Redux is there to first take the state out of the React components. Now I know I showed you that Redux is a simplification of Flux. That is because there are no concepts of dispatcher, for example, in Redux and you also work with a single global store, as opposed to the Flux implementation where you could have had as many stores as you liked. So those are all some differences, but in a way they are simplifying the entire Flux architecture. So Redux is there to take the state out of the React components, which means that the components themselves become very specialized and they become focused on rendering only, which is when they do this one thing and one thing well. They are concerned only about rendering your data to the UI.

So the moment we take the state out of the components, we gain a lot of advantages. For one, testing becomes easier because we now have a separation of concerns. This is a very good programing pattern or principle that we should always try to apply in our code base. Besides taking the state out of the components, Redux also provides, let’s say, a guideline for how data must flow inside the application. And this guideline is very easy to understand and follow. There is this buzzword or syntax that’s very popular inside the React, Redux, Flux systems. Mainly the uni-directional data flow. And this is what Redux and React both achieve together.

Basically the global store in Redux can dispatch actions every time something needs to change in the state as a result, or as a consequence of a user action. Let’s say, for example, we code a button, or we scroll, or we do something else – that action is being treated and its effects are being determined by applying a series of reducers over the application state. Reducers are actually the core concept in Redux. You can see the similarity in the name there. So Reducers are basically pure functions that do not mutate the state directly, but always do changes and return new copies of the state. This function purity thing is a concept we can find a lot of in functional programming, and it is also one of the things that allows for ease and implementation of time travel debugging.

So reducers operate on the state, and after all the changes are complete, the global store notifies the interested parties via events. It notifies components because those are the interested parties – the React components that use that shared state. The store notifies the components that something changed, and when that happens, the components pull the latest information from the store and re-render themselves and their children, of course. So this whole pairing of React and Redux works so, so great because it’s simple, it’s concise, it’s easy to follow and trace the steps that take place and how each step along the way effects your application.

It promotes a separation of concerns, so now each part of the system deals only with certain responsibilities. Redux deals with the state management and React only deals with the rendering. So I would say that in a couple of words, this team of React and Redux greatly simplifies the way developers can reason about their application state, which is always a very good thing to have.

Julia Slattery: What do you all think the future of React holds? Do you think more companies will start to adapt it?

Cassian Lup: That is a really good question, and it is something that a lot of people are thinking about because a few years ago, if you were to tell somebody what the future of JavaScript looked like, there would have been a handful of people that would have guessed we would be here today. Because it has taken this incredible expansion and the rate in which it is going is just fatiguing to some. So this term fatigue has been highly debated in the UI world and over the past year. Saying that if you want to keep up with everything that is going on in the JavaScript world is impossible. You need to learn and learn and you never get to know everything.

But it is somewhat understandable because of the constant changing nature of the JavaScript ecosystem. It was about five years ago that I heard about Atwood’s Law for the first time. It said that whatever can be written in JavaScript will eventually be written in JavaScript. So with that in mind, React has proven that it is here to stay. You jump over the initial discomfort of writing declarative UIs – some people might construe it as discomfort. But you are set. The performance, ease of use, and power that you get are truly better than the competition.

I went to a big conference in the last year and I heard Angular quoting saying that they were working on Angular 2. They were working on React and borrowing concepts from there. They are saying that; they are not hiding that fact. In fact, they are priding themselves on that because the Facebook team did such a great job with the concepts behind the React that it is just a common way of doing things now. So it is definitely here to stay and it is probably going to be adopted by more and more projects.

Vlad Zelinschi: You know, React made a great impact in the community. In a way, React was one of the promoters of a couple of good ideas that developers are now embracing when they are building their UI applications, like going for a component-based approach and a component-based architecture. Or this whole re-render thing and single data binding. So when React came out, it definitely made a great impact and I also think it is here to stay around for a while. Now, more and more companies are starting to adopt it with great results both in development speed as well as code clarity and maintainability. Personally, I am aware of at least five React-based project that we have at 3Pillar at this moment and I am pretty sure React will be a part of the technical stack for other projects that will come in the future as well.

I am also very excited about React Native and all of the efforts that Facebook and the community around are putting into that. Although, in my opinion, it is still not mature enough to develop complex multi-platform applications like Target and iOS, as well as Android, at the same time. I think that definitely paved a very interesting direction inside the JavaScript community and there is more to come from this React Native initiative. So the efforts there are really exciting and they can only bring good news in the future. So I would say the things to come look very exciting and I, for one, can’t wait to see what they bring.

Julia Slattery

Julia Slattery

Marketing Content Writer

Julia Slattery is a Marketing Content Writer for 3Pillar Global in our Fairfax office. She manages content for 3Pillar’s web properties, hosts 3Pillar’s ‘Take 3’ podcast, and assists with the production and editing of a wide variety of audio, video, and written content. She holds a BA in Writing, Rhetoric, and Technical Communication from James Madison University.

Leave a Reply

Related Posts

Take 3, Scene 14: The Present and Future of Angular 2, Part ... On this two-part episode of Take 3, Cassian Lup and Andrei Tamas join us all the way from Romania to discuss the newest iteration of the AngularJS fra...
Take 3, Scene 14: The Present and Future of Angular 2, Part ... On the second part of this two-part episode of Take 3, we continue our conversation with Cassian Lup and Andrei Tamas on the newest iteration of the A...
Spell Check and Autocorrect with Conditional Probability A client of mine wanted to reduce the time it took for his vendors to upload an inventory list to his system. The system currently matches the product...
Jonathan Rivers Interviewed by CXO Today on Cloud and Smart ... Jonathan Rivers, Chief Technology Officer for 3Pillar Global, was recently interviewed by India's CXO Today on 3Pillar's developments in the newest cl...
Blockchain Trends: 2016 Year in Review In October 2015, 3Pillar Global embarked on a trailblazing journey to build a trading platform on blockchain. This post is the first one of a series d...

Free product development tips delivered right to your inbox