React全家桶：石墨文档大前端技术选型分享

正文

请到「今天看啥」查看全文

Angular 在这三个当中应用得最为广泛，团队中也有几个人有过 Angular 开发经验。但经过仔细分析，Angular 1 已经能嗅出一点衰落的味道了，而且 Angular 2 的前景尚不明朗。相比而言，处在上升期的 Vue 虽然表现出了不错的潜力，但在那时生态仍然显得不够成熟，选择其作为网页版的核心框架非常冒险。所以既具有不错的潜力，社区也相对活跃的 React 成为了我们最后的选择。另外当时 React Native 已经发布，相关的生态圈也在飞速发展逐渐繁荣，这成为选型天平上倾向 React 的一个不算轻的砝码。

React 带来的变化

相对于 Angular 和 Vue 而言，React 对于 JavaScript 工程师的水平要求更高一些。尤其是在大型项目中，对 React 不熟悉的情况下很容易写出难以维护或性能低下的代码。我们在迁移到 React 的初期，由于团队只有少数几个人接触过这个框架，所以经历了一段时间的「阵痛」，例如对于 shouldComponentUpdate 的错误使用使得一些错误变得不易追踪调试。不过随着大家的不断实践，React 逐渐给项目的开发带来了非常积极的影响。开发新功能的效率得到了显著的提高，同时凭借组件化，团队之间的分工更加明确，代码也更加利于维护。

移动端：React Native

在 2015 年团队决定全面转向 React 时，恰巧 React Native 刚刚发布。虽然 React Native 并不是我们选择使用 React 的最终原因，但是其也为之后移动端的技术选型和石墨文档前端团队的构建思路埋下了一个伏笔。

从原生到 React Native

2016 年，我们的 iOS 和 Android App 均是使用原生语言（Swift 和 Java）开发的，随着用户量的逐渐增多，用户对 App 的功能需求也越来越多，其中之一就是离线支持。离线支持对于石墨文档的场景来说是一个非常复杂的功能，需要处理离线时多层级文件结构的移动、创建、删除以及权限的同步问题。讨论技术方案时发现如果在每个平台（包括我们的网站）重新实现一遍的话成本非常高。

当时我们正好在做移动端 App 的新版产品设计，涉及到的产品改动很多，恰好此时后端也在进行数据接口化的重构，同样依赖移动端不少的改动。于是我们想到了趁此机会使用 React Native 对现有 App 进行重建的方案并立即开始了调研。调研的结果非常乐观，虽然当时很多人声称 React Native 有很多坑，但是我们也看到了一些激动人心的成功案例。考虑到当时整个前端团队的技术积累都在 React 栈中，而且我们的移动端 App 开发工程师也有不错的前端基础，所以最终决定将移动端彻底转向 React Native。

请到「今天看啥」查看全文