说到react，我们很多人都知道，有人问react native，还有人想问现在做前端怎么样，这到底是咋回事？其实react native呢，今天我们就来看看react native，希望对大家有帮助。
react native
属性前面的三个点（...props），是延展操作符。 在React中，延展操作符一般用于属性的批量赋值。比如
var props = {};
props.foo = x;
props.bar = y;
var component =
等同于
var props = {};
props.foo = x;
props.bar = y;
var component =
使用延展操作符的好处是，当你的属性有所增加的时候，组件中的使用不需要去增加对应的属性。
html5现在还占优势的。
1、开发方式
（1）代码结构： React Native更为合理，组件化程度高
（2）UI布局：Web布局灵活度 > React Native > Native
（3）UI截面图：React Native使用的是原生组件，
（4）路由／Navigation：React Native & Native更胜一筹
（5）第三方生态链：Native modules + js modules = React Native modules
2、性能 & 体验
（1）内存：Native最少；因为React Native含有框架，所以相对较高，但是后期平稳后会优于Native。
（2）CPU：React Native居中。
（3）动画：React Native动画需求基本满足。
（4）安装包体积：React Native框架打包后，811KB。相比热更新，可以忽略和考虑资源规划。
（5）Big ListView
（6）真机体验：Native >= React Native > H5/Hybrid
React Native有什么UI框架可以使用吗?
React Native Android版本预计2015年10月发布。（见React Blog Round-up #26）
其他支持Android的框架：
NativeScript，这东西就是太重，功能看起来还是很强大的 NativeScript/NativeScript · GitHub
Google Sky，用Dart写跨平台应用，卖点是“120FPS”，组件模式借鉴了React，目前还处在实验阶段。 domokit/sky_sdk · GitHub
react native 怎么实现记住用户登录状态
1、首先在controller包下创建UserAction类。
2、添加如下注解。
3、在类中写两个login方法，一个用于get到login页面，一个用于post到登录后的主页。此处注意redirect和forward的区别。
4、post方法如下。
5、mhead.jsp如下。
注意事项：
React Native使你能够在Javascript和React的基础上获得完全一致的开发体验，构建世界一流的原生APP。
现在前端怎么样？React-Native 需求量大吗
靠谱的前端从来都是大需求，相当难找。 React Native 适合展示类 UI 或 复杂类表单 业务场景。如果你的 App 需求涉及到 设备硬件（如蓝牙、摄像机等） 或 操作系统 API 调用（控制系统 Wifi 等，在 Android 系统中尤其明显），不建议使用 React Native 。 React Native 是 View 层的一个实现方案，跟 App 开发是两回事，不看好 一个 App 使用纯 React Native 开发（虽然官方 demo 都是纯 React Native ），建议部分页面采用（热更新；不涉及系统调用的复杂 UI ）。
react native是做什么
React Native 结合了 Web 应用和 Native 应用的优势，可以使用 JavaScript 来开发 iOS 和 Android 原生应用。在 JavaScript 中用 React 抽象操作系统原生的 UI 组件，代替 DOM 元素来渲染等。
React Native 使你能够使用基于 JavaScript 和 React 一致的开发体验在本地平台上构建世界一流的应用程序体验。React Native 把重点放在所有开发人员关心的平台的开发效率上——开发者只需学习一种语言就能轻易为任何平台高效地编写代码。
怎么把react 转到react native
环境同
浏览器环境 ReactDOM （般react）渲染标签
手机客户端环境
ReactNative 渲染没标签应使用类标签
所同环境 react 组件部缝迁移需要自进行封装
react native 怎么样
React.native是目前唯一靠谱有前途的移动跨平台解决方案。
搞移动跨平台，解决方案已经有过很多了。Xamarin, Cordova, 基于webView的PhoneGap, 还有一大票各种创业公司的方案。它们都很垃圾。原因很简单：为达成“一次编写到处运行”的目的，这些方案不得不对两个主要平台（iOS和Android）的SDK做进一步的抽象，这意味着它们只能兼容两个平台共有的组件，结果就是写出来的app只能做到最平庸的用户体验。特别是微软的Xamarin，连自家的Windows Phone都搞不好，还给Apple和Google的SDK做包装，那能好么？基于Web的方案就更不用说了，本质就是拿HTML套个壳外加一些原生写的插件。
React.native的高明之处在于：它并不追求一次编写到处运行，它放弃了全部代码跨平台这一不切实际的目标。RN的目标很实际：用同一门语言（Javascript），同样的高层架构（Virtual DOM）和设计模式（component-based），针对不同平台分别作出最佳的用户体验。这也就是RN中“native”一词的含义。
在实际开发中，要做到最佳用户体验，针对iOS和Android应该要分别编写UI代码的。实际上RN也鼓励这么做。Android是Android，iOS是iOS，web是web，三者有不同的界面语言和用户习惯，凭什么要一样呢？但除却UI，业务逻辑、data object、web call等等却是可以一样的。再加上采用了同一门语言和设计模式，RN在生产力上非常有竞争力。从另一方面看，Flux设计模式反过来也被原生开发社区接受，Redux库在Java和Swift上都有翻版原生实现，所以你不一定要用RN写app，但你还是可以借鉴采用React的设计模式。React项目对于整个开发社区的影响很正面，比PhoneGap这种催生了一大票廉价app码农的垃圾技术正面多了。
另外，纯Javascript的开源库也可以直接应用到ReactJS／ReactNative中，这也进一步提升了生产力。
学习React Native需要先学习React JS吗？
学习React Native不需要先学习React JS，两个没什么大的关联。React Native (简称RN)是Facebook于2015年4月开源的跨平台移动应用开发框架，是Facebook早先开源的UI框架 React 在原生移动应用平台的衍生产物，目前支持iOS和安卓两大平台。
拓展：
1、RN使用Javascript语言，类似于HTML的JSX，以及CSS来开发移动应用，因此熟悉Web前端开发的技术人员只需很少的学习就可以进入移动应用开发领域。
2、React Native主张"Learn once, write everywhere"而非其他跨平台工具一直宣扬的"Write once, run everywhere"。通过React Native，开发者可以使用UITabBar、UINavigationController等标准的iOS平台组件，让应用界面在其他平台上亦能保持始终如一的外观、风格。
我为什么暂时放弃了React Native
去年三月份，以及十一月份，我分别做了两个 React Native (下称 RN )的项目，一个是一个很简单的充值页面，发上线以后就基本不维护了，暂且不表；另一个是把我们客户端首页的技术方案由 Hybrid 迁移到了 RN ，跟进并维护了几个版本以后，又决定切换回了 Hybrid 的方案，以下记录一下我这段时间的心路历程以及我对 RN 的看法。
背景
我们首页迁移 RN 主要有以下几个原因
公司的架构组对 RN 的支持度比较高，有一个比较完整的解决方案，包括打包体积的优化，封装了 redux 和路由，方便业务方的开发
我们的前端代码优化力度不够， bundle 的体积很大，首屏会比较慢，在 Android的 WebView 里尤其明显，而且代码时间也比较久，想要拆包优化也需要大量的时间去测试，然后之前做的 RN 项目几乎是秒开，给了我们很大的诱惑力。
前端的框架是 React ，前期调研了一下觉得切换的成本很低，这是我们最终决定迁移 RN 的原因，也是我们预估的最失败的地方，遇到的问题我在之前的博客里有提到过。
就像我之前的博客所说，我花了大概20天的时间做了这次迁移，其实真正估时的时候并没有这么久，主要是在开发上踩了一些坑，项目最终上线后的效果也很棒，首屏的渲染时间快了很多，尤其是 Android ，就当我们为此庆祝并且准备继续迁移的时候，问题慢慢展现出来了。
问题
主要的矛盾在于要维护两个工程。
咱们的首页既要服务于 Touch 端，又要服务于客户端，之前的客户端是 Hybrid 方案，矛盾并不突出，只需要在我的前端代码里对客户端做一些特殊处理即可，但是迁移 RN 以后我们就需要维护两套代码了。就像我之前说的，我们过于乐观的觉得，从React 的代码到 RN 其实并不需要做过多的转换，甚至考虑着自己写一套转换的脚本，实现无缝对接，现实却是来了当头一棒。
比如，css无法复用, Android 下的 overflow:visible 就是不可用的，比如不支持百分比布局，比如不支持 fix ，导致我们在两边的切图还是不能使用一套方案。
又比如：加大了需求开发的成本和时间，比如PM有一个需求，单做前端可能2pd，算上 RN 可能就是3pd，对于一个创业团队会拖慢自己的进度，而且只能找有Mac的同学来做这个需求 = =。
就不说调试难，以及开发一些需求的时候需要请教客户端的同学是否支持然后去找对应的方案了。而如果是 Hybrid 的方案，只需要 web 和 native 讨论好接口，分别开发即可。
最终，在维护了几个版本的 RN 后，我又毅然的将方案改回了 Hybrid
我的看法
这是一次失败的尝试，却不是一次无用的尝试，在我看来， React Native 是一项非常棒的技术，我们不需要针对客户端开发两套代码，而且整体体验是优于 Hybrid的。但是我还是觉得采用这项技术之前大家要考虑清楚，我个人觉得，对于大公司的大团队，业务需求不是特别紧的团队，都很适合采用这一项技术，对于我们反而是不太合适了。
经过这件事我对技术选型也有一些思考。技术选型时，应该选择根据自己的团队，自己的需求，花费很多时间调研以后再去决定，而不是选择一些火的方案。比如我们之前移动端选择使用 React ，就是觉得以后还是要做自己的客户端，用了 React 以后切换 RN 会是一件很小成本的事，结果现在还是采用的 Hybrid 方案。现在又因为React 包体积很大，不得不对项目再做一些优化。
希望大家在选择 RN 时，也考虑清楚，我是否对 Web 的需求很低，我是否有很强的跨平台需求，我的技术人员是否可以hold住一些场景等等，而不是因为它很火选择它。
这个吗？
