Talk about React,flux,reray and GRAGHQL.

a few days ago to see colleagues forwarded the "reacteurope Conf participants ' impressions,This article is about some of the ideas of react, but I react finally be able to achieve a good learn once, write everywhere or skeptical, after all, the world is diverse, Apple's iOS (flat style), Google's Android each has its own UI specification (Material design and AngularjsMaterial Designeven if the idea of react is good, it is not always possible to make much progress on other people's turf. But in the Web front-end domain, react as the innovator, inevitably will promote the entire front-end development progress.

The rapid development of the front-end development in the past few years, the personal feeling mainly for a number of reasons: the Internet industry on the user experience of high requirements and complex front-end projects, leading to the previous jquery framework and plug-in front-end code is gradually complex, not keep up with the rapid changes in demand, code expansion leads to maintenance becomes a problem, This is the actual demand for a new framework; the front-end project has a relatively short life cycle, some activity pages may take a few days, the general master page will be a large revision for several months, the equivalent of the server side, the front end of the history of less burden, engineers are more likely to use new technology to provide development efficiency The natives of the Internet have started to write code, and many of them may have been developed from the front, and they prefer to introduce new frameworks from abroad. This is one of the reasons why react is now very hot.

I feel the problem with react now is that the goal is too big to be a web front-end, to do the native iOS page, and then to engage the Android native UI. Although Facebook has a strong research and development capability, the concept of Virtual dom is a bit like the JVM of the UI layer, but we all know that even though the JVM has been doing it for more than 10 years, it is mainly used on the server, and the support for cross-platform is not particularly ideal, and the UI domain is more perceptual and diversified. , the dependency on the UI primitive layer is more complex, the mobile platform has its own UI specification, and the difference is very big, so the foreground of vdom on the mobile side is not optimistic. For mobile development, react vdom is equivalent to creating a new development approach on Apple and Google's turf, and there will inevitably be a game of interest. In particular, the Android platform is complex, various versions, different resolutions, various manufacturers of custom-made devices, a variety of custom UI, it is doubtful react can hold the back, I estimate react Android October jump ticket possibility is big.

Here's the flux architecture. Flux is a Facebook-developed application architecture that uses unidirectional data streams for   react now the flux architecture is just a concept, the lack of official standards to achieve, third-party implementation is a bit messy, Even our company has a iflux architecture, There are too many frameworks, and there is bound to be a unification, and some of the flux frameworks will definitely die or merge later.

Relative to Angularjs,react is not a complete front-end solution, many places also need to supplement, this has made the technical ability of the team requirements, and the ANGUARJS framework is relatively perfect, suitable as the overall front-end development solution for use, suitable for large-scale engineering development. As for Angularjs 2, wait until the browser can generally support ES6 time to consider it.

personal feeling behind relay will gradually replace flux. Relay is a new framework for Facebook's first public debut on React.js Conf (January 2015) to address data-tier issues for react applications. in relay, each component uses a query statement called GRAPHQL to declare a dependency on the data. Components can usethis.propsaccess to the data obtained. developers are free to assemble react components, while relay is responsible for the data query statements of different components (the originalquerycentrally and efficiently organize and process, provide accurate granular data to components (no excess data), notify corresponding component updates when data changes, and maintain a data cache with all data on the clientstore.

        Finally, graphql. GRAPHQL is a query statement that describes complex, nested data dependencies. It has been used for many years on Facebook's native app. on the server side, we are configured to map GRAPHQL to the underlying data query code. This layer of configuration allows GRAPHQL to access different underlying storage systems. Relay uses GRAPHQL as a data query statement, but does not specify a specific implementation of GRAPHQL.  

        I think GRAPHQL is a good idea, probably the most promising in the series. graphql does solve some of the rest API pain points, especially in the mobile network environment, the interface returns too much redundant data, the problem at the current mobile network traffic fee is not cheap, It's important to be fast enough. GRAPHQL's development prospects are promising, but there is a need to improve the ecological environment, especially Java-based implementation framework, Android and iOS client Support framework, with these things to really promote the popularization of GRAPHQL, Currently only the node. js version is not enough, after all, most server-side projects are not node. js, most server-side engineers are not proficient in JS. On Android clients, there are already plenty of rest-supporting network scenarios, such as spring Android,google volley.

The above text is only a personal opinion, as to whether to use react according to specific projects and research and development team situation specific analysis.

Copyright NOTICE: This article is the original blogger article, reproduced please retain the source Http://blog.csdn.net/offbye

Talk about React,flux,reray and GRAGHQL.