Elm体系结构：将R隐藏在FRP中

函数式反应式编程在移动应用程序开发中风靡一时。 在我以前在Ackee工作期间，我们是ReactiveCocoa / ReactiveSwift的早期采用者。 最初，其他团队可能会因学习曲线而推迟，但到现在，大多数公司已经看到了某种形式的反应式编程，并且许多公司正在包括iOS和Android在内的不同平台上使用Rx框架。

MVVM-OOP的最后一口气

使用FRP，将所有不同的数据源连接到几乎是声明性的视图层就像以可观察的形式存储状态一样容易。 您只需要一个放置这些可观察属性的位置和一些将值填充它们的业务逻辑即可—您需要一个ViewModel。

但是MVVM有它的问题。 您可以以一种方式绘制所有箭头（即View-> ViewModel-> Model ），但是在另一个方向上仍然存在通信。 您声明了反应式绑定，而不必理会它们，就像箭头没有出现一样。 它只是有效…除非出现死锁。 更糟糕的是，找到此类死锁的根源（无论是递归事件还是在错误的时间发送多个信号）都不是最困难的问题。 修复它。 通过使用反应式框架，您已经声明了代码可以处理我们向其抛出的任何输入， 无论何时我们 选择扔它。 除了现在，它不能。 您应该如何解决这个问题？ 一个简单的skipRepeats()有时会有所帮助，但有时您最终会编写诸如.skip(first: 2)或.delay(0.0, on: QueueScheduler.main)并祈祷该项目在无法管理之前结束。

此外，ViewModels是对象。 您已经在内部用FRP替换了OOP，但是您的应用仍然由这些需要协调的有状态的参与者组成。 当两个ViewModel需要共享某种状态时，您可以掷硬币— “头说我们将其放在’服务’中，尾部是’经理’”。 无论哪种方式，它都是另一个有状态的对象。 这些之间的通讯又如何呢？ 您是否曾经想过编写ManagerManager？

在撰写有关iOS应用程序体系结构的文章时，我已经知道这是我对MVVM的再见。 我对此非常满意，赞赏过去几年为我所做的一切。 但是现在该继续前进了。 现在该摆脱所有这些行为，反应，通讯，同步并导致不一致和死锁的对象了。 现在该停止像没有并发那样行动，而要真正做好随时准备参加任何事件的准备。

效果也可以将事件反馈到程序中，视图也可以。 效果分为命令（用于发出HTTP请求）和订阅（用于侦听数据更改（套接字，本地和远程数据库等））。 因此，我们的最终更新层如下所示： 

  func update（来自模型：Model，带有msg：Msg）->（Model，Cmd ）
 func订阅（用于模型：模型）-> Sub

和我们的视图层： 

  func view（for model：Model）-> ViewDescription

我失去了时间。

本文越来越长，但这不是我的意思。 我过去是将FRP出售给学生的是功能编程+时间 。 我曾经知道反应性信号如何同步。 我很擅长。 随着时间的流逝，您的眼睛开始看到潜在的死锁，就像它们在ARC环境中呆了一段时间之后开始看到内存泄漏一样。 但是现在我可以采用上述3个函数，将它们推入所谓的ReactiveAutomaton （它会执行您的想法），而不必理会FRP中的R。

当然，长时间运行的Command可以在意外的时间产生事件，但是现在我们比以往任何时候都更加在意。 如果要添加逻辑，只需将必要的信息存储在模型中： 

 让ignoreTheCommandResultCauseTheUserHasLoggedOut：布尔

顺便说一句，它很可能已经存在： 

  var ignoreTheCommandResultCauseTheUserHasLoggedOut：Bool { 
    返回！isLoggedIn 
 }

我们必须始终期待出乎意料的意外，但是我们正在收获如此丰厚的回报。 状态恢复和时间旅行，具有很好的可组合性和可测试性，但对我而言最重要的是纯函数式编程。 能够仅使用数据转换来编写交互式应用程序确实是一项壮举。 时间的概念仍然存在，我们无法摆脱它。 但是它存在于郊区，在我们应用程序的边框中。 而且我们听说未来可能非常渺茫。

它会做动画吗？

是。 大概。 老实说，我不在乎。 当React刚问世时，每个人都在强调缺乏动画支持。 我敢肯定，很多人说他们不会因为这个原因而使用它。 但是他们仍然做到了。 那么谁在乎呢？ 好处是存在的，并且有很多人不愿意忽略它们。 是的，我们将制作动画。 这可能会更复杂。 从修复愚蠢的错误到实现动画，项目经理可能不得不重新分配一些时间。 但这不会太糟。 从iOS8开始，默认情况下CAAnimations是可添加的，因此现在就使用它们，一切都会好起来的。 和性能？ 我们可以谈论很长一段时间。 到我们结束讨论时，这将不再是一个问题。

所以这似乎是要走的路。 我们的移动程序员具有一个很大的优势-如有疑问，我们可以看看两年前网络的发展。 我坚信，这些反应式自动机，这些具有反馈回路的单向应用程序是移动应用程序开发的未来。 那样的未来将使更多的人开始编程，因为它是如此的容易。 对于您，经验丰富的开发人员，这将是一件轻而易举的事。 毕竟，这只是功能性反应式编程减去时间 。 谁知道，您甚至可能有时间编写一些测试。

Interesting Posts