反应原生，原生

使您的Swift应用更具React Nativey

自白

我要告诉你一个肮脏的小秘密。 有时候，我很想念React Native。

我知道我知道。 感觉很不对劲。 但是其中有些感觉是正确的。 反应性的，声明性的UI代码？ 热装？ 可以绕过应用商店的更新？ 而且即使Javascript在很多方面不如Swift出色，它也变得相当不错（新的异步/等待和Flow的渐进类型检查）。 我一直不时地尝试它， 希望它变得惊人，并让我摆脱所有在iOS开发中发疯的事情。 当然，它并非没有缺点，但某些功能却非常有趣且富有成效-谁不想玩得开心又富有成效？

对于我们这些人来说，React Native并非可行之举，如果我们仍然可以在编写Swift的同时获得一些功能呢？ 今天，我们将探讨如何拥有反应性的，声明性的UI代码和热重载应用程序数据，从而节省大量测试时间。 另外，也许我们可以做一些绕过应用商店进行更新的事情吗？

反应式，声明式用户界面

React Native使我们可以编写UI代码，感觉更像是对UI的描述，与配置和转换所有数据的逻辑分离。 我们没有花哨的虚拟DOM React，但是我们可以解决这个问题。

Reactor是我编写的一个小型Swift库，灵感来自Elm，Redux，以及Benjamin Encz等人撰写的出色ReSwift著作。 请参阅文档以更深入地了解Reactor，但是我们正在使用的基本模型是：

查看示例项目，看看它是如何完成的。 但这几乎就像您可能想象的那样：我们的状态旨在使用Marshal进行序列化/反序列化，然后将其全部与我们的体系结构和文件监视程序一起使用。

我认为这里有很多潜力：重新创建用户报告的错误状态，无需重新编译即可测试UI，轻松检查应用程序的当前状态……各种有趣的东西。

绕过App Store

我们正在迅速接近已知的iOS世界的终结。

由于其解释性，Javascript不仅可以热重载代码，而且可以热重载已通过网络接收的代码。 这带来了A / B测试的整个可能性，绕过了应用商店进行某些更新和安全漏洞。 😛

正如我们之前讨论的那样，我们无法热重载Swift代码。 但是，我们知道可以热装应用程序数据。 那么，如果我们将更多的UI表示为应用程序数据怎么办？ 也许我们可以编写一些可重用的组件，并且数据本身会告诉我们它要使用哪个UI组件。 正如约翰·桑德尔（John Sundell）所展示的，这是Spotify正在做的事情。 观看该视频。 很酷，很酷的东西。

结论

React Native从iOS社区获得了一些帮助。 尚未尝试过的开发人员可能不应该得到很多，但像所有工具一样，它也都有其优点和缺点。

也许这些缺点在您的项目中对您不利。 这并不意味着我们不应该垂涎专家，也不应该试图弄清楚如何将其他领域的出色软件开发人员的想法应用到我们自己的领域中。