What do you think about React and Flux / Redux? What’s your favorite view library?

Editor’s note: In this interview, we interviewed Steven, our web-developer. Steven had worked on various JavaScript-based projects at Oursky, where different frameworks were used based on different requirements. When it comes right down to it, React.js is his “favorite” hands down.

War between AngularJS vs React paradigms

AngularJS vs React has always been an exciting yet embarrassing struggle when creating a new project for JS developers in recent months. The two frameworks have quite different approaches to building a web or mobile app.

Question: What do you think about about Angular.js?


It makes it easy to write apps in the MVC methodology – build controllers (Controller) and directives (View), serve Models from service = less deep in JavaScript’s callback hell by using data binding.

The powerful directives make it easy to inject behaviors – directives provide the ability to describe both layouts and behaviors, because it is not restricted to be an element. For example, if I want to make some parts of my app to change its background color in a specific pattern. This can be easily done by injecting a standalone directive.

Thanks to Dependency Injection (DI), it’s very easy to unit-test Angular.js apps.

Question: So… why do you choose React.js?


1. It’s purely JavaScript.

Everything – everything is in pure JS! It sounds opinionated, or more like a personal preference, but hear me out:

With an app written purely in JS, it’s much easier to debug your app. In the Angular way, you got logics in JavaScript, and you got logics that live inside the HTML templates. Good luck in finding which line caused the bug!

On the other hand, it’s easier to search for the things that don’t work, when you just need to search in one file – the react component itself. Even when the component grows big, it’s just one file.

2. It does its job well – as a view renderer.

When writing your app in React.js, you just need to think about “WHAT” should be updated, but not “HOW” to update it.

React.js maintains its own virtual DOM, and only the necessary parts are updated in the view when something’s changed. Performance, in most cases, is no longer a concern even if you are building complicated and large applications / components.

3. Code review made easy.

When you start working with React.js, you will soon be able to recognize a well-written component just by looking at how it manages its props and states – a good component makes it easily predictable.

Another thing to look at when reading a React component is to see if there are any states that it shouldn’t be holding.

Writing React components – some “rules” I picked up along the way:

In React.js, there are smart components, and there are dumb components:

  • A smart component is a controller. It knows how to handle events, transform the data it holds and pass them to children. They hold their own state;
  • A dumb component is a pure UI component. It only knows how to transform data, from its parent to children, and transform events from its children to parent. They communicate by passing data or callbacks in props.

Here’s an example of dumb component:

class DumbBookListextends React.Component {     // other functions      render() {     <div> this.props.books.map(this.renderItem) </div>   }   } DumbBookList.propTypes = { books: React.PropTypes.array }; 

An example of smart component:

class SmartBookListextends React.Component {     getInitialState() {     return { 'books': [] }   }     // other functions   fetchBookList() {     // ...     SomePromise.then((res) => { this.setState({ 'books': res }) })   }     render() {     <div> this.state.books.map(this.renderItem) </div>   }   } 

In many cases, you can tell how dumb or smart a component is by counting the number of states a component holds. Dumb components are safer to use, because they only transform what you give them and what they return – you can’t miss anything. But in reality, components are seldom purely dumb because a smarter component can have more functionalities, sharing the works with their parents and making it simpler. (That being said, React v0.14 introduced Stateless function components , which encourages dumb components.)

React components are usually very verbose – you may measure the smartness of a component easily by:

  • Looking at the name of the component. (naming! it makes a difference!)
  • Finding the ‘getInitialState’ or ‘setState’ of the component and ask yourself why the component declared something as a state, instead of a prop.

As a very generalized rule – a React.js app should have as many dumb components as possible because they are always safe to use, and don’t handle events silently. The smarter a component is, the harder it can be reused.

4. It’s cross-platform.

It’s hard to find a device that doesn’t support JavaScript nowadays, but that’s not the point.

With React Native released and the abstracted rendering, theoretically , you just have to learn React once and you’re ready to start building your interface for Web, iOS and Android. Even more platforms may get supported in the future (even for Windows!) – as long as Facebook and the community continue to produce new rendering engines.

Editor’s note: More will be discussed on the practicality of React Native in a future post.

5.Redux, that’s why!

If you’re familiar with Flux – the uni-direction data flow methodology proposed by Facebook, then you are at a good position understanding Redux – Redux is a predictable state container for JavaScript apps (Ref: https://github.com/reactjs/redux )

Redux, as an architecture works very well with React and makes it easier for you to manage the state of your apps.

Editor’s note: See the section for Flux and Redux below

Question: Is there any drawbacks of using React?


It requires some time to understand how to work with React’s props and state to make a production-ready app in React. You will want different components to communicate with each other — but if you don’t fully understand it, you might end up doing something like calling a function on a child component, which leads you to hold a “ref” of it and ruins the abstraction and the separation of components.

Animating your elements might be very tricky. Also, implementing animations in React.js and React Native are quite different.

Unlike other similar libraries, say Angular JS which was designed for Web and is almost used exclusively for Web, React.js was designed to be cross platform. As mentioned above, as long as new renders are written, existing React code can also be run on new platforms other than Web, iOS and Android – theoretically.

What makes it tricky is that, as React is only responsible for describing the layout’s structure, while there are limited support for animations for both React DOM (Web) and React Native (iOS and Android), in many cases, adding animation to your view isn’t as easy as it would have been if you’re using other libraries like jQuery.

What makes React so special?


This question is by nature a very opinionated one, but here’s my reasons: I simply think the React way is the way an app is supposed to be built.

When building an AngularJS app, you focus a lot on finding the right ‘ng-stuff’ or building a better one, whereas when building a React app, all the focus are on the construction and composition of components. React components are like dynamic and configurable HTML elements, while not having to deal with DOM manipulation or observing states.

In a nutshell: it makes sense, and it works well!

So – I made a big fuzz about “Flux” and “Redux” above, but –

What the is flux?


  1. It makes sure unidirectional data flow.
    1. The store itself only expose getter method.
    2. All events would travel through dispatcher and then the stores.
    3. It makes debugging much easier, because you always can tell ‘who’ made that happen.
  2. It prescribes that you concentrate your model update logic in a certain layer of your application.
    1. Instead of mutating the state directly, you dispatch plain objects that are called “actions”

It’s all nice as it sounds, but why I did not choose Flux?

  1. Flux is only a concept, but I want something ready to be used.
  2. Multiple stores would be created to manage the application state for a particular domain within the application.
    1. Stores would have dependencies between each other.
    2. It requires some efforts to trace why a store mutates itself upon an action, especially when there is a “waitFor()” in the registered callback.
      1. https://github.com/gaearon/flux-react-router-example/tree/master/scripts/stores

I tried Flux, then I went for Redux

So what is Redux?

Redux is not purely a Flux implementation but was inspired by Flux.


  1. Unidirectional data flow, events → state changes → view changes.


  1. Instead of making multiple stores, you compose a single big state tree.
  2. Changes are made with pure functions.
  3. Separation of the store and the one who changes the store.

Why I chose Redux

  1. Start using it is just as simple as: npm install redux .
  2. Easy for review, because it enforces functional programming and all state changes are made within reducers. You can easily tell if a certain part of function contains logical error, simply by matching the event name and the function body. (So naming is very important here.)
  3. Easy for testing, because it enforces functional programming.
  4. https://github.com/gaearon/redux-devtools saved my life.

How React works with Flux/Redux

  1. Without flux/redux, the smart components are usually the top-level components in the hierarchy, which holds most of the app states.
  2. Flux/Redux acts as a even higher level, so those states are moved to the store.
  3. Those high level components would instead query the states they need from the store. And events would be passed to Action Creators.
  4. Originally:
    1. let state = { … }<App>

      <PageA {…state.pageA} />

      <PageB {…state.pageB} />


  5. With Redux:
    1. <Store>


      // the states are come and update from the <Store />

      <PageA mapStateToProps={(state) => state.pageA} />

      <PageB mapStateToProps={(state) => state.pageB} />


      </Store>// in real wrold, with Redux

      class PageA extends React.Component {// other functions

      render() { … }


      // MAGIC!

      // PageA is then managed by the Redux Store

      export default connect(PageA.mapStateToProps)(PageA);

That’s it for now! So what do you think about React + Flux / Redux? What’s your favorite view library? Let us know in the comment below!

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » What do you think about React and Flux / Redux? What’s your favorite view library?

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址