Explore the react eco-circle

Original address: Http://www.csdn.net/article/2015-08-04/2825370-react

In the 2004, it was a milestone year for the front-end community. Gmail turned out to be a native app-level experience based on front-end rendering that boosted the time and touched the user's G-spot relative to the previous service-side rendering of the Web page. Since then, the front-end rendering site has been the direction that countless developers are chasing.

To better develop front-end rendering of "native-level" sites, a series of front-end frameworks, including backbone and angular, came into being and quickly gained large-scale adoption. But soon, new performance and SEO problems followed. After several attempts, Twitter even renders back to the server from the front-end rendering, and strikingly has faced the same thorny problem.

In 2014, react into our sight. What's refreshing is that react is confident in answering the questions that other open source frameworks face. With almost no hesitation, we started using react to reconstruct strikingly. A few years later, as we look back, we may find that 2014 is also a milestone year for the front-end community.

React Introduction

What exactly is react? Facebook simply and quietly defines it as a "JavaScript library for building the UI." This definition may be reminiscent of many JavaScript template languages (such as handlebars and swig), or early control libraries (such as Yui and dojo), but the core concepts that react is based on make it very different from those of the template and control libraries. In fact, these core concepts are very advanced and have brought impact on the entire front-end world. They include:

1. Components and component-based design processes;
2. Unidirectional data flow;
3. The virtual DOM replaces the physical DOM as the manipulating object;
4. Replace the HTML template with JSX syntax and declaratively describe the UI in JavaScript.

These simple principles put together a number of benefits:

1. Both front-end and back-end are able to render pages from react components, completely solving the problem that SEO has plagued JavaScript single page application for a long time.
2. We can simply write the front-end test directly and forget the DOM dependency completely;
3. Component encapsulation and unidirectional data flow can greatly simplify the understanding of the front-end architecture.

Let's look at an example:

[JS]View Plaincopy

1. var hellomessage = React.createclass ({
2. Render: function () {
3. return <div>hello {this.props.name}</div>;&nbsp;&nbsp;
4. }
5. });
7. React.render ("John"/>, document.body);

This react version of Hello World has shown some of the core features of react. First, HelloMessage is a react component; When we create react applications, we always start with components. At the core of each component is a render method, in which we assemble the props and state of the component into a template that is ultimately rendered, and then return to the template (this is, rather, a UI description than a template in the traditional sense). The part of the code that looks like HTML is the famous JSX syntax, which is the best way to describe "templates" in react.

Now, in the first paragraph beginning with Var, we define a component called HelloMessage, and the next react.render this line is to render this component into document.body-that is, our actual page. But when using 〈hellomessage/〉, we did another thing: Name= "John". It looks much like an element attribute in HTML, but since JSX is not HTML, what does this syntax do? In fact, this is how we passed the react component to the props. Looking back at the first paragraph, we can see that there is a reference to this.props.name inside the component. This name is the john! we just named.

See here, if you're familiar with jquery, you might be thinking, what's the fundamental difference between this and $ (document.body). html (' Hello John ')?

This is where the virtual Dom comes in. We write jsx like HTML, but JSX does not directly become HTML and DOM. Behind the scenes, react maintains a virtual DOM, and the "physical" dom, which is actually manipulated directly by the browser, is just a projection of the virtual DOM. The virtual DOM does not depend on the browser environment, it can run in any JavaScript execution environment. This allows the following code to be made possible:

[JS]View Plaincopy

1. var html =react.rendertostring ("John"/>); res.send (HTML);

If the second line looks familiar, you're not mistaken-this code happens on the server side! Yes, the same hellomessage, we can not only let react render to the page at the front end, but also can render the HTML string directly on the back end, and then return it to the front end. The service-side pre-rendering is happening so naturally.

The revolutionary innovations react brings are the most exciting changes in the front-end world over the past few years. Since contacting react, we have been convinced that react will revolutionize the development experience of client developers, including front-end, iOS and Android. In the following space, we want to share the progress and future trends of the react ecosystem and community from four big directions-target platform (Targets), data Processing (data), tools, and new challenges.

Target platform

For the discussion of virtual DOM, many people would say faster than the real DOM. Such discussions can be a quick way to understand react, but people who have actually written the react application will understand that speed is not the essence of virtual DOM. We believe that the existence of virtual Dom has helped us to do two things. The first is a statement-style UI. The virtual Dom,ui is no longer a constantly notconsistent dom, you just have to assert how the UI is generated, and react will automatically help you render the UI changes to the real DOM. This new way of thinking allows you to not manually manipulate the real DOM. The second is multiple target. We've been talking about the web, but react let us do the target beyond the Web. Virtual Dom is more like a UI virtual machine that automatically maps you to a real implementation, which can be a browser dom, IOS UI, and Android UI. Someone even did it. React maps to the terminal text UI.

Multi-targets is one of the main topics that the react community is often discussing. The root of multi-targets is to improve the developer experience. The developer Experience (Dx,developer Experience) is a concept that has been repeatedly mentioned in the react community. How to improve the developer experience while maintaining the same user experience is a question that the front-end community, including react, is thinking about. In fact, any company with multiple clients faces the same problem: reinvent the wheel in a variety of client languages. Developers need to learn new languages, write and maintain similar features. Improving the client developer experience is about reducing learning costs and maintenance costs. This is the "learn once,write everywhere" advocated by react.

There have been some encouraging news lately. The Facebook internal Ads Manager iOS version was completed by 7-bit front-end engineers with react native for 5 months. While the Android version, is the same as EM, completed within 3 months. The code reuse rate reached 87%.

Multi-targets can also be a more in-depth combination on a single platform. Sebastian Markbåge, from the React core team, gave a stunning speech at the Reacteurope conference, "DOM as a second-class citizen". In his speech he imagined react directly to the bottom of the browser architecture (Figure 1, the rendering architecture of the browser, Figure 2 is what Sebastian Markbåge think react can do).

Figure 1 The browser's rendering architecture

Figure 2 Sebastian Markbåge think react can do a lot of things

Let's not talk about it, it's exciting to open up such opportunities through virtual DOM. It also shows that Facebook has been thinking about transcending DOM when designing react. The idea is really ahead.

"Service-side pre-rendering (pre-rendering)"

For other mainstream front-end frameworks, page SEO and first-time speed issues are a headache. Twitter was too slow for the first time and even returned to the server rendering scheme. People have been looking for a solution that only needs to write a UI component and both the front and back end can be rendered at the same time. If we can do that, we can first open the page with the server to render the page HTML, when the browser has been received after the page can be displayed. This allows both SEO and first-time open speeds to be resolved. This perfect solution is called the Isomorphic/universal App in the community.

React native support for pre-rendering (server-side rendering). Because of the virtual DOM, it means that we only need the backend to run the JavaScript engine to render the entire DOM. The current mainstream back-end language can run the V8 JavaScript engine. For example, strikingly's backend uses Ruby on Rails, and only the open source React-rails gem can be used to render front-end react components on the rails backend.

When using server-side rendering, be aware that the global variables that are available to Windows and document are nonexistent. The react component provides these two lifecycle Hook:componentdidmount and Componentdidupdate will not be run on the server, only on the front end. When using server rendering, you need to put the code in these two lifecycle hook definitions if you want to use any browser-only variables.

Data processing

React defines itself as a view in MVC. This allows front-end developers to start thinking about UI design from V. But now there is no universally accepted approach to data manipulation and acquisition methods in the community. This is also the most difficult place to handle when writing react applications.

"Flux"

The concept of flux is proposed for M and C,facebook. Flux is an application architecture designed specifically for react: applications are made up of dispatcher, store, and view, where view is our react component. The core of flux is the one-way data flow shown in 3.

Figure 3 Unidirectional Data flow is the core of flux

Any data changes in the application are initiated as action, distributed through dispatcher, received and consolidated by the relevant store, and then provided to the view (React component) as props and state. When the user does any data-related interaction on the view, view initiates a new action and opens a new data change cycle. This unidirectional nature makes flux much easier to understand at a high level than the traditional MVC architecture and bidirectional data binding represented by angular and knockout, greatly simplifying the developer's thinking and debugging process.

After the announcement of flux as a design model (rather than a well-established framework), a new flux library appeared almost every month, they all had their own features, some were better for server rendering support, and some used more functional programming concepts. Many of the flux libraries are more like experiments, which help to react ecological growth, but there is no denying that there will be a lot of flux libraries dying in the future, and only a few will survive or merge.

"GRAPHQL"

When building large front-end applications, front-end and back-end engineers collaborate through the API. The API is also a mutual agreement. The mainstream approach now is the restful API, but in practice we find that restful is not very well suited to the needs of some real production environment. Often we need to build custom endpoint, which goes against restful design concepts.

For example, we want to show forum posts, authors, and corresponding messages. We have to make three different requests respectively. The second request relies on the user_id returned by the first request result, and the front end needs to write the dependencies between the code coordination requests. Each of the three different requests in the mobile side of this network unstable environment, the effect is not ideal.

[JS]View Plaincopy

1. Get/v1/posts/1
2. {
3. "id": 1,
4. " title":"react.js in strikingly",
5. "user_id": 2
6. }

[JS]View Plaincopy

1. Get/v1/users/2
2. {
3. "id": 2,
4. "name":"Dfguo"
5. }

[JS]View Plaincopy

2. Get/v1/posts/1/comments
4. [{
6. "id": 6,
8. "name":"Rechtar",
10. " comment":"Thanks for sharing! I would love to see some examples on graphql. "},{
12. "id": 9,
14. "name":"Tengbao",
16. " comment":"I heard that the guys also use immutable.js. How does it help? "},{
18. "id":
20. "name":"SYJSTC",
22. " comment":"impressive work! Thanks guys! "
24. },{
26. "id":
28. "name":"abeth86",
30. " comment":"Thanks for the sharing!"
32. }]

To solve this kind of problem, the engineer will customize some endpoint. For this example, we can create a/feeds endpoint that aggregates all the results needed by the front end:

[JS]View Plaincopy

2. Get/v1/feeds/1
4. {
6. "id": 1,
8. " title":"react.js in strikingly",
10. "User": {
12. "id": 2,
14. "name":"Dfguo"
16. },
18. "Comments": [
20. {
22. "id": 6,
24. "name":"Rechtar",
26. " comment":"Thanks for sharing! I would love to see some examples on graphql. "
28. }...
30. ]
32. }

But we may only need post and user in some scenarios and don't want to comments. Is it time to define a feeds_without_comments endpoint? As demand changes, custom endpoint methods often make API interfaces cumbersome and violate restful design concepts. Any data needed by the front-end engineer needs to be changed by the back-end engineer, which reduces the iteration speed of the product.

The GRAPHQL from Facebook is what I think is the closest perfect solution. Back-end engineers only need to define the type System that can be queried, and front-end engineers can use GRAPHQL to customize the query. The GRAPHQL query statement only needs to describe the shape of the data that needs to be returned:

{
       post(id:1){
            id,
            title,
            user{
                 id,
                 name
           },
          comments{
                id，
                name,
                comment
          }
     }
  }

The GRAPHQL server will return the correct JSON format:

[JS]View Plaincopy

2. {
4. "id": 1,
6. " title":"react.js in strikingly",
8. "User": {
10. "id": 2,
12. "name":"Dfguo"
14. },
16. "Comments": [
18. {
20. "id": 6,
22. "name":"Rechtar",
24. " comment": "Thanks for sharing!  I would love to see some examples on graphql.
26. }...
28. ]
30. }

GRAPHQL also natively supports API versioning, allowing you to coexist with multiple versions of clients at the same time (both Web and mobile). This reduces the coupling between the client engineer and the backend engineer and increases productivity.

The GRAPHQL specification was introduced in July this year and the JavaScript GRAPHQL Library was open source. But for GRAPHQL to become mainstream, Facebook needs to build an ecosystem like react. To use GRAPHQL on your own application, you must also have back-end languages to provide support for GRAPHQL libraries. For example strikingly needs graphql Ruby Library. This requires not only front-end engineers. We think this will be more difficult to establish than the react ecosystem (see Figure 4). Facebook needs the involvement of the entire community to reach it.

Figure 4 GRAPHQL Eco-System

"Relay"

Relay is Facebook's proposal to apply graphql on react. The base unit for react is the component (Component), which is a combination and nesting component for building large applications. Component-based design patterns are the most recognized in the community today, and this is one of the trends in the front-end world. The data required for each component should also be defined within the component. Relay allows the component to customize its required GRAPHQL data format, and then graphql the server to fetch the data when the component is instantiated. Relay also automatically constructs the GRAPHQL query for nested components, so that multiple nested components only need to make a single request. Relay will be open source in August.

"Immutability"

The react community accepts many of the ideas of functional programming, which are deeply influenced by Clojure. The use of immutable data is from the Clojure community. That year OM, this with clojurescript write react wrapper on the speed incredibly end abuse native JavaScript version of the react. This shocked the whole community. One reason for this is that Clojurescript uses immutable data. Immutable.js is also popping up in the react community, which makes it possible to use immutable data in JavaScript, perfectly compensating for the congenital inadequacy of JavaScript in the data object comparison. Immutable.js has also become a must for building large react applications. There are even discussions about whether to include immutable.js directly in the JavaScript language. We believe that small applications do not encounter the performance bottlenecks of virtual DOM, and introducing immutable.js only makes data manipulation cumbersome.

Tools

工欲善其事, its prerequisite. React's popularity is driven by tools from the community, and react is driving the progress of these tools. Here we want to introduce some of the more popular tools in the react community.

"Webpack"

In react, compiling code using tools such as Webpack or browserify has become a part of the front-end engineer workflow because of the need to use JSX. The Webpack is a powerful front-end module management and Packaging tool (see Figure 5). Some of its features are listed here:

1. Supports both COMMONJS and AMD modules;
2. Flexible and extensible loader (loader) mechanisms, such as support for JSX, ES6, and less;
3. Support for the packaging of CSS, images and other resources;
4. Can be packaged into multiple files based on configuration and intelligent analysis;
5. Built-in powerful code splitting function to split and dynamically load packages;
6. Development mode supports hot module replacement mode to improve development efficiency.

Figure 5 Front-end module management and packaging tools Webpack

"Babel"

The ECMAScript 6 (ES6) specification was finalized in April this year, and the react community embraced ES6 in general. But there are still many browsers that don't support ES6. Compiling the code with a tool like Webpack allows us to use ES6 (or later) in development to compile the ES5 before the launch. The most notable thing in the compilation Tool is Babel. Formerly known as Es6to5,babel, the most popular ES6 in the community to compile to ES5, the Facebook team has even decided to switch to Babel and no longer maintain the jstranform used internally. With the loader mechanism, Webpack can be very easily combined with Babel applications.

"React-hot-reload"

In developing any large front-end application, we often need to re-refresh the entire page because of some minor errors. React-hot-reload try to solve this problem and improve the development efficiency. He used the hot Module replacement feature of Webpack, dynamically replacing the lifecycle hook definition of the react component, and updating code changes without refreshing the page.

"React Developer Tool"

This official Facebook Chrome plugin allows you to easily see the react component structure directly in your browser. Once installed, a react Tab appears in the Chrome developer tools. The interface is just like Dom inspector, just looking at the react component structure relationship. is one of the rare tools for developing react applications.

Challenge

React is rapidly opening its borders, which means that we face many new challenges as we gain new joy. Now around a few big issues, the react community has yet to reach a conclusion that new experimental projects are being tried each week or even every day to solve these problems.

Animation

Everyone has been confused about how the animation should be expressed as a state in react. Cheng Lou's React Tween state is what we think is most in line with react thinking. The displacement exists in the state, and the new location is dynamically rendered via JavaScript. However, there has been a reservation on whether the practice will be satisfactory. In this year's Reacteurope speech, he showed us a great effect and speed, well worth a look.

In strikingly, we took a more pragmatic approach to animation: we defined some container components, such as 〈jqfade/〉 and 〈jqslide/〉, in which jquery's animation method was invoked to implement the corresponding transition. This approach is not entirely consistent with react's spirit in theory, but so far it has been able to meet our needs.

"Flux Library and relay"

As already mentioned, the various implementations of flux today are flourishing, and there is no authoritative factual standard. Relay is also a new concept that has just begun to hatch-all of which means that while Flux+relay can lead to a rise in productivity, it will take time to actually use them.

"CSS"

CSS is an interesting topic: everyone seems to feel that the current CSS has a deep flaw, but the idea of how to solve these shortcomings is divided into two factions conflicting: the school thinks that CSS "can be repaired", and is committed to repair it, resulting in the creation of cssnext such projects Another faction thinks that CSS is fundamentally a thing that was born in an ancient age, and has not been able to adapt to the modern development process of large-scale, modular, which is reflected in Christopher Chedeau's speech "React:css in JS" In which he raised the seven fundamental questions of CSS and then pointed out that using inline CSS directly in JavaScript would solve all of these problems almost "free". Inline CSS has always been a suppressed negative practice in traditional web development best practices, and now we can look at it in a completely new light, which is also a perfect example of how react really is driving the entire front-end world in a fundamental way.

Summarize

In the recent jsconf 2015, the front-end Moore theorem was put forward: the front end would be one-fold every 1 August. The front end has changed so quickly because we are facing an unprecedented engineering challenge. Today's front-end complexity is not a grade at all a few years ago. This also encourages the community to find tools and design patterns that can maintain the development efficiency and development experience in this complexity. React community from other areas (game rendering, Clojurescript, functional programming) to steal the teacher, combined with the unique problems faced by the front-end, a series of solutions. The react community is pushing the front-end community forward in every way. This is good for the community as a whole. We also hope that the front-end frameworks can learn from each other and collectively drive the development of the community as a whole.

Explore the react eco-circle