react框架源码理解（react框架菜鸟教程）
本文目录一览：
Web前端主流框架—React的优缺点分析
React：
1.声明式设计：React采用声明范式，可以轻松描述应用。
2.高效：React通过对DOM的模拟，最大限度地减少与DOM的交互。
3.灵活：React可以与已知的库或框架很好地配合。
优点：
1.速度快：在UI渲染过程中，React通过在虚拟DOM中的微操作来实现对实际DOM的局部更新。
2.跨浏览器兼容：虚拟DOM帮助我们解决了跨浏览器问题，它为我们提供了标准化的API，甚至在IE8中都是没问题的。
3.模块化：为你程序编写独立的模块化UI组件，这样当某个或某些组件出现问题是，可以方便地进行隔离。
4.单向数据流：Flux是一个用于在JavaScript应用中创建单向数据层的架构。
5.同构、纯粹的javascript：因为搜索引擎的爬虫程序依赖的是服务端响应而不是JavaScript的执行，预渲染你的应用有助于搜索引擎优化。6.兼容性好：比如使用RequireJS来加载和打包，而Browserify和Webpack适用于构建大型应用。它们使得那些艰难的任务不再让人望而生畏。
缺点：
React本身只是一个V而已，并不是一个完整的框架，所以如果是大型项目想要一套完整的框架的话，基本都需要加上ReactRouter和Flux才能写大型应用。
以上就是青藤小编关于Web前端主流框架：React的优缺点分析的相关分享，希望对大家有所帮助，想要了解更多相关内容，欢迎大家及时关注哦!
React框架有哪些优点？
React都是属于目前比较主流的前端框架,但是我们通常会选择项目比较适合的框架。
React优点：
1.声明式设计 −React采用声明范式，可以轻松描述应用。
2.高效 −React通过对DOM的模拟，最大限度地减少与DOM的交互。
3.灵活 −React可以与已知的库或框架很好地配合。
4.JSX − JSX 是 JavaScript 语法的扩展。React 开发不一定使用 JSX ，但我们建议使用它。
5.组件 − 通过 React 构建组件，使得代码更加容易得到复用，能够很好的应用在大项目的开发中。
6.单向响应的数据流 − React 实现了单向响应的数据流，从而减少了重复代码，这也是它为什么比传统数据绑定更简单。
我们在实际项目开发选型中一般大型项目会选择React。
React作为时下最热的前端框架，各位有什么经验分享下吗
1. 不要陷入纠结工具的怪圈
我们团队一开始用 React 的时候，工具栈应该是 grunt +
grunt-react；写了一段时间感觉有局限，然后老大带头把工具换成了 gulp + browserify + watchify +
reactify，然后又愉快的写了大概半年吧，发现流行的库都上 webpack 了；于是我们的工具栈又变成了 gulp + webpack +
babel-loader。最后大家一致认为 gulp 是多余的，所以我们的工具栈又围绕 webpack
重新搭建了一遍。到最近我负责的一个内部项目，什么 hot-module-replacement、extract-text-plugin（让你在
js 里 require('style.scss'); 这么写的玩意儿）一股脑的造。当然再后来因为业务需要我们又基于 webpack
搭建了自己的构建工具，这是后话……
这将近一年半的折腾历史告诉大家，1) 前端就是个大坑，1个月不学新知识你就会被社区遗忘 2) 现在上 React 真幸福，工具栈基本都稳定了（什么？你还不懂？用 webpack！），不用花太多时间纠结。
PS. HMR 也就那样，虽然 dan 吹得神乎其神，但实际在项目里我发现大家还是习惯手动 Cmd + R
，因为项目大了以后 rebuild 也需要 1、2 秒。
2. DOM 操作是不可避免的
但
凡是上点儿规模的前端项目，没有 DOM 操作基本是不可能的。且不说最常见的后端「埋点」，你总得用 DOM API
去取值吧；就说一个最简单的，比如右手边这个「回到顶部」的按钮，你纯用 React 写一个试试。当然你会说什么
requestAnimationFrame，什么 ReactCSSTransitionGroup blah blah
blah，真正到项目里你会发现还是 DOM API 简单。
3. 拥抱 ES 6，拥抱 React v0.14
这俩为什么放在一起说呢？因为 React v0.14 里提出了一个全新的组件概念叫做：无状态的函数式组件（Stateless functional components）。它大概长这样：
var Aquarium = ({species}) = (
Tank
{getFish(species)}
/Tank
);
有没有发现被传统的 createClass 方法精简了很多？当然这样写组件也有很多局限，比如不能声明各种生命周期方法等等，但是在常见的前端业务场景中，纯 render 的组件不在少数。在这样的语法推出后，我们就能把这些组件更方便的抽出来复用了。
此外，拥抱 ES 6 还有很多的好处，比如在加载依赖的时候不用先 var xxx = require('xxx'); 再 var yyy = xxx.yyy; 而是可以直接 import {yyy} from 'xxx'; 简洁明了。
4. 生态环境仍然在成长中，坑不少
其
中首先要口诛笔伐一下的就是 react-router，我们从 v0.10 开始用，到现在
v1.0。你知道为了升级这玩意儿我们改了多少次业务代码么？每次升级 API 都要变，无力吐槽。当年好不容易搞懂了
v0.11，在博客里写了篇技术文章分享，结果后面的日子就是各种被催更……一个月前抽空就 0.13 版又重写了一遍教程，这不 1.0
版又出了，API 基本全都不一样了！！不一样了！！一样了！！样了！
当然除了坑也有不少高质量的生态环境产品，比如蚂蚁的 ant design。
5. Server 端渲染很美，至今没看见哪个规模级的产品用到
可能是我孤陋寡闻吧，欢迎评论中跟进。自己摸索着写过一个最简单的 server 端渲染，但是这套逻辑如果套到我们现在的业务逻辑中，几乎可以直接枪毙。为了实现 server 端渲染需要做出的 trade off 太多。
6. React 很简单，也很难
简单是因为 React 的 API 真的很少，官网的各种文档花一个下午也能看个七七八八（此时此刻再看看 Angular……）。但是当你以为你真的搞懂 React 的时候，看看React 源码剖析系列 － 解密 setState - pure render - 知乎专栏这篇文章开头提的问题，有多少人能不假思索的答对呢？（顺便安利一下，我们团队的知乎专栏，目前处于死磕 React 的状态）
当你真正在业务项目中使用 React 的时候，你会发现它的生命周期比你想象的复杂；它的 API 背后的逻辑比你以为的麻烦。当然，首先你要踩进这个坑。
7. 对于楼上某位仁兄表示《React：引领未来的用户界面开发框架》这本书太难的回答，作为译者之一表示对不起你。作为补偿，所有购买本书的同学均可凭拍照私信我咨询 React 相关的问题。
