September 19, 2016
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.
- 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?
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.
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?
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?
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.