React Strict DOM：React Native 通用应用步伐的将来

                             
Meta公布发布了react-strict-dom。从根本上讲，这将改变我们使用 React Native（以及在网页上使用 React）的方式。它提供了一套同一的 UI 原语，带有样式，可以在网页和移动装备上通用使用！现在，“编写一次，到处摆设”对于那些在通用 RN 范畴的人来说并不是消息——react-native-web 已经存在多年，可以处理惩罚将 RN 的源码转换为网页· DOM· 元素。这是一种 ·RN ·优先，网页次之的方法，但是付出了肯定的代价。     
     本文探究了为什么react-strict-dom很告急，它与 react-native-web有何差别，以及为什么你应该感到高兴！
     配景

     RN UI 在网页和移动装备上的实验

     在网页上使用 React Native 的告急里程碑的时间线

                                 

                             
“编写一次，到处运行”的愿景早在 2015 年 React Native发布后就产生了，人们开始思索怎样在网页和移动装备上都使用RN。Nicolas Gallagher 在 2016 年发布了 React Native Web，作为 React Native 和React DOM 之间的互利用层，从根本上将 RN 的组件和 API转换为网页组件。Twitter Lite使用`` React Native Web 创建了仅用于网页的组件，而且至今仍在为 Twitter 网页版提供大部分组件。     
     与此同时，微软的开发职员开发了 ReactXP，这是他们怎样弥合 React网页版和 React Native之间 UI 层差距的方式。这个项目得到了很大的关注，并被用于 Skype。终极，ReactXP 在 2020 年被弃用。
     与此同时，Expo 的开发职员也不停在致力于实现通用视觉。早在 2019 年，Expo公布支持进入 web 测试版。从当时起，Evan Bacon 不停在积极构建 Expo 在 Web 上的 RN视觉。在 2020 年，Evan 发布了怎样使用 Metro 打包 web应用步伐的演示。到 2022 年，Expo Router 被公布推出，这是 ``Expo 关于怎样使用遵照网页和移动尺度的导航路由器来驱动web和移动装备的单一代码库的看法。Expo Router 在底层使用 Metro，同一了应用步伐的网页和移动版本的打包过程。
     淘汰 React DOM 和 React Native 之间 API 碎片化的 RFC：react-strict-dom

     在 2022 年 8 月，React Native Web的创建者 Nicolas Gallagher创建了一个RFC，发起应该积极淘汰 React在网页上与 React Native之间的 API 差别。最初被称为“strict DOM”，这是 React DOM 的子集。
     该 RFC的重要目的是：
     

• 进步网页上的性能
  
• 使 React开发职员更轻易转向React Native
  
• 实现更高质量的“通用”应用步伐。
  

     Nicolas和 Meta 的其他职员（以及来自开源社区的麋集讨论和发起）在一年多的时间里不停在积极推动这一工作，直到 2024 年 2 月推出。
     为什么 react-strict-dom 云云告急？

     固然社区不停在积极实现通用应用步伐的愿景，但直到 RSD发布之前，Meta从未“认可”这一点。Meta总是推许“学一次，到处编写”的标语，暗示 React Native可用于多个平台，但须要为每个平台举行差别的实现。这与社区不停向着“编写一次，到处运行”的愿景相反。RSD是Meta初次正式认可的跨平台UI办理方案，涵盖了网页和移动装备。
     深入相识细节，这些是我以为这是一件非常告急的变乱的重要缘故起因！
     Meta 自己正在使用它

     当你在 Github 上检察 react-strict-dom存储库时，它提到Meta的团队已经在生产中使用 RSD，以“更快地发布功能，覆盖更多平台，并淘汰工程师数量”。

                                 

                             
Meta 对UI的“通用”办理方案的直接投资意味着它将加速其发展。别的，假如 Meta将其用于生产中的应用步伐，这意味着它将在一些最频仍使用的网站/应用步伐中颠末实战测试，这天然意味着它将被非常优化和可扩展化。     
     网页性能提升

     我对 React Native Web 的一个标题是它是一个相当巨大的依靠项。假如没有启用树摇，捆绑巨细靠近300KB。加上 React-DOM的约 125KB，你的依靠项仅处理惩罚捆绑就有约425KB（只管这些是未压缩的巨细）。这是由于 React Native Web实验覆盖 React Native API的整个实现，因此将不得不支持大量大概不想在网页上使用的功能。
     比方，Animated API ``在 react-native-web中高出70KB的巨细，而且依靠于JS层来执举措画，这比仅使用 CSS 进举措画要慢。同样，您大概不想在网页上使用 VirtualizedList、PanResponders 和其他React Native `生态体系的组件。
                                 

                             对于 react-native-web，转译和支持 API的负担在网页应用步伐上，这大概会导致性能降落，由于诸如 SEO 排名之类的缘故起因。
     React Strict DOM接纳了一种险些相反的方法。它将兼容性和 API 的翻译负担放在了移动端，那里可以更充实地处理惩罚将 API映射到原生层功能的负担。假如有任何性能丧失，这已经存在于React Native 工作方式的核心，此中JS层必须将视图、文本和其他元素委托给原生层实现。
     将 React 开发职员池与 React Native 更靠近

     拦阻 web开发职员从 React 切换到React Native 的重要因素之一是API的庞大差别。Web开发职员风俗于 DOM，这也是使 React起首具有吸引力的缘故起因之一。您可以使用<div>、<input>、<button>和险些任何其他在 DOM中存在的元素，险些不须要修改（最初对人们来说最大的狐疑通常是从 class切换到 className）。
     React Native 显然更加受限定 - 开发职员须要熟悉一组界说精良的 API，这些 API与 DOM类似，但在根本上却有很大的差别。这意味着开发职员开始使用 React Native存在着明显更大的学习曲线。
     RSD担当DOM元素，并通过引入对React开发职员来说更加熟悉的API来消除开发职员从 React迁移到 React Native 时的认知负担。
     不但是 API，作为 RFC 的一部分，诸如重新计划 React Native变乱循环以使其更靠近 web 变乱循环之类的变乱也正在举行中。
     关注点

     原生装备上的性能

     React Strict DOM中将翻译层从网页端移至原生实现大概会对移动应用步伐的性能产生负面影响，这是一个匿伏的关注点。React Native 在性能方面不停备受质疑，因此测试这一点并确保使用 RSD不会出现任何退化黑白常告急的。
     为了相识性能影响，我举行了一些开端测试，使用Flashlight渲染了一个 Flatlist中的1000个项目（手动覆盖任何假造化），每个项目都有一个视图和一些文本。
     从我的根本测试中，我发现React Native和 React Strict DOM险些产生了类似的结果，这是一个令人鼓舞的迹象。但是，这只是一个非常根本的测试，须要更大范围的测试，测试更多的 API 外貌来更正确地相识性能影响。
                                 

                             对于现有的通用应用步伐的现实接纳操持

     另一个思量因素是现有应用步伐使用 react-native-web 或平常 RN怎样迁移到 react-strict-dom，而无需对其代码库举行大规模改造。抱负环境下，应该有一条安稳的迁移路径，最大限度地淘汰手动修改的需求。
     我想到的一些想法是使用代码转换来主动处理惩罚大部分迁移。这大概涉及自界说的 Babel设置或其他构建时工具，将现有的 React Native Web代码转换为与 React Strict DOM 兼容的代码。
     另一种方法大概是积极地将 UI原语抽象为自界说组件，这些组件现在使用 React Native Web，但将来可以轻松地与 React Strict DOM 相当的组件举行更换。通过赶早构建这个抽象层，迁移到 React Strict DOM 大概会更轻易。
     更现实的环境是，像 Tamagui和 Gluestack如许的盛行通用 UI 库也可以通过抽象掉 React Native Web 和React Strict DOM之间的根本差别来促进迁移。由于这些库已经在RN API之上有了抽象层，以是在它们将来接纳 RSD的环境下，创建在这些库之上的应用步伐应该可以大概在险些不修改代码库的环境下从 React Native Web 切换到 RSD。
     何时稳固？

     这天然引出了末了一个标题。RSD 在一个多月前公布。它仍处于实行阶段，RSD何时可以预备投入生产仍然不清晰。在为原生应用步伐预备停当之前，仍然有很大一部分 API 外貌须要涵盖。
     最初的RFC 是在 2022 年夏季开放的，这表明开发已经举行了约莫两年。思量到项目的范围和复杂性，假如再过一两年才完全稳固，那也屡见不鲜。
     总结

     对于 React Native社区和更广泛的React生态体系来说，这是一个令人高兴的时间。看到 Meta使用 RSD进入通用应用步伐范畴意味着由大型科技公司接纳了一个代码库可以驱动原生应用步伐 + 网页的愿景。这个积极将意味着作为一个社区，我们将看到更高质量、性能更好的通用应用步伐，而且将来将会有更多的工具来促进它们的构建。
             ©  著作权归作者全部,转载或内容相助请接洽作者        

喜欢的朋侪记得点赞、收藏、关注哦！！！