星球狂想战队|React 迁移的利与弊，耗时三年，向( 二 ) 2017年

国际化和本地化移动应用的翻译工作主要有两部分组成：内容文本和平台文本。前者来自学院的内容管理系统，包括互动练习中的问题、视频的内容和字幕或文章中的文字。（许多内容文本是前面提到的“流主题树”的一部分。）平台文本是在移动应用的代码库中定义的，如“注册”按钮中的文字、标签栏项目的标题或“设置”页面中显示的文字。
可汗学院有一些优秀的自制基础架构来维护平台文本。在JavaScript中定义一个字符串，然后就可以使用开发团队编写的，将字符串复制到原生iOS和Android字符串的脚本。这个工具很好用，团队可以轻松地在原生和ReactNative上重用字符串，这在“跨越”迁移阶段有很大帮助。
从2015年至2019年，可汗学院的应用仅支持六个语言版本，但现在已达到了19个！共享的iOS和Android实现帮助团队构建了流主题树，这意味着添加其他语言不会让应用的体积大幅增加。此外，团队能够在ReactNative中设计轻松处理非拉丁字符的组件。应用的语言版本数量不再有技术瓶颈，而只取决于学院有多少翻译库可用。这极大地鼓舞了学院的国际倡导者，让他们更好地为世界各地的用户宣传可汗学院。
ReactNative的体验迁移到ReactNative并不是一帆风顺的，途中有很多坎坷，例如学习新语言、新的组件生命周期等。 “跨越”时期尤其具有挑战性。原生代码和ReactNative代码之间的桥梁有很多烦人的样板代码。
团队成员很想念Swift的关联值枚举、方便的初始化器、命名参数以及轻松向结构和类添加函数和变量的特性。
但ReactNative也有很多好处。
ReactNative比UIKit更具延展性。调整和重构代码的体验很不错。例如，为UICollectionView编写的代码与UITableView和UIStackView是不一样的，但是在ReactNative中并不用操心这一点？在大多数情况下，你可以在重构时剪切并粘贴代码，将某些内容从网格更改为列表是非常简单的。开发工具非常好用。方便的VSCode插件、linter和自动修复器，大大减轻了开发人员和代码审核人员的负担。就算开发人员并不怎么熟悉Android应用开发，也可以使用ReactNative编写Android应用。熟悉ReactNative后，应用开发团队也有信心参与Web前端的开发工作了。现在的成果可汗学院的iOS和Android应用现在共享一个代码库，开发团队可以专注于应用的功能开发，用不着关心平台的差异。这意味着随着时间的推移，应用的功能质量会越来越好，并且团队可以对功能进行渐进式改进了。
共享的基础架构使团队更容易迁移到GraphQL ，从而简化了服务端向Go的迁移工作。应用的体积明显缩小了。从大型内容库数据库切换到流式数据库，极大地减少了应用体积。应用的开发团队与网站团队联系更紧密，两边的设计和功能也得以互通，整个组织的协作水平得到了提升。应用中仍然有一些原生代码，必要时团队可以继续使用Xcode或AndroidStudio实现特定于平台的功能，例如iPad多任务处理。团队创建了强大的设计系统，可帮助可汗学院的设计师和工程师快速协调产品的改进方案。下一步计划可汗学院目前的主要工程项目是Goliath ，内容是将后端重新设计为一系列Go服务。统一的移动基础架构在这一迁移过程中起到了作用：虽然移动团队只有六名成员，也还是能继续构建新功能和修复程序。团队改善应用的功能、本地化、质量和性能的能力比以前强了很多。
本文最初发布于khanacademy.org网站，经网站授权由InfoQ中文站翻译并分享。
原文链接：/our-transition-to-react-native/
关注我并转发此篇文章，私信我“领取资料” ，即可免费获得InfoQ价值4999元迷你书！