纯函数式编程语言

by Bobby Schultz

由Bobby Schultz

函数式编程正在接管具有纯视图的 UI 。 (Functional Programming is taking over UIs with Pure Views.)

The last couple years have seen a huge improvement in how UIs are developed by using Purely Functional Views. In functional programming a “pure function” is one that when run, returns a value but does not change anything outside its scope (also known as side-effect free function). This greatly reduces the cognitive load and permutations in applications so that they have a massive reduction in bugs (see case study), easy to understand, compose together and incredibly stable.

在过去的几年中，使用Purely Functional Views开发UI的方式有了巨大的进步。 在函数式编程中，“纯函数”是一种在运行时返回一个值但不更改其范围之外的任何值的函数(也称为无副作用函数)。 这极大地减少了应用程序的认知负荷和排列，从而大大减少了错误( 请参阅案例研究 )，易于理解，组合在一起并且异常稳定。

David Nolen has one of the best explanations for this type of pattern of UI development ƒ(d)=V. It’s a function that receives data as its input and returns a view. No scoping, binding, subclassing, external access to variables or any side effects. This makes it very predictable with drastically less regard to the context that a Pure View is run in. In the JavaScript world you could say, Given any JSON will ALWAYS create the same HTML, CSS and event listeners.

对于这种类型的UI开发模式ƒ(d)= V， David Nolen给出了最好的解释之一。 该函数接收数据作为输入并返回视图。 没有作用域，绑定，子类化，对变量的外部访问或任何副作用。 这使得它非常可预测，而无需考虑运行Pure View的上下文。在JavaScript世界中，您可以说，鉴于任何JSON都将始终创建相同HTML，CSS和事件侦听器。

为什么纯视图不同于其他UI模式？ (Why are Pure Views different than other UI patterns?)

In order to fully understand this we need to understand what we’ve been implicitly doing for years in our code. Code is written as a series of complex permutations. Each function we call changes something outside it’s private scope. We then call another function that changes something else. If the data or order of these functions calls deviate in any way bugs occur in unexpected ways. Think about the times you fixed a bug that was caused by something seemingly unrelated in the other class or server somewhere. These are large permutation issues.

为了完全理解这一点，我们需要了解多年来在代码中隐式所做的事情。 代码被编写为一系列复杂的排列。 我们调用的每个函数都会在私有范围之外进行更改。 然后，我们调用另一个更改其他功能的函数。 如果这些函数调用的数据或顺序以任何方式偏离，则错误会以意外的方式发生。 考虑一下您修复由某个类中的其他类或服务器中似乎无关的东西引起的错误的时间。 这些是较大的排列问题。

Take a look at the chart below. This is how we internally think about our applications.

看看下面的图表。 这就是我们内部思考应用程序的方式。

Super clear, right? Call `login()`, then `getUser()` then `getCart()`. In reality our application flow includes error paths, unexpected values, network and thread operations. If they return in a slightly different order or the data is slightly different or the data is mutated by multiple classes in our applications these will cause bugs. This is a more accurate model of possible branches:

超级清晰吧？ 依次调用“ login()”，“ getUser()”和“ getCart()”。 实际上，我们的应用程序流包括错误路径，意外值，网络和线程操作。 如果它们返回的顺序略有不同，或者数据略有不同，或者数据在我们的应用程序中被多个类突变，则将导致错误。 这是可能分支的更准确模型：

If anything doesn’t travel on an expected path at the expected time we get bugs. OOP Classes are supposed encapsulated data, events and transformations inside its boundaries to make this work without bugs. Obviously we all have bugs. Systems are hard because they are complex and those complexities cause bugs.

如果在预期的时间没有任何东西在预期的路径上移动，我们将得到错误。 OOP类被认为是在其边界内封装的数据，事件和转换，以使该工作没有bug。 显然我们都有错误。 系统之所以困难是因为它们很复杂，而这些复杂性会导致错误。

简单轻松 (Simple Made Easy)

For anyone who has learned the about Gang of Four and Object-Oriented Patterns but not seen Rich Hickey’s talk “Simple Made Easy” go watch it now. The core concept Hickey talks about is how too many externalities is a major reason why we don’t fully understand what our code is doing when we read it. It’s not easy because too many plates are spinning at once. Object Oriented languages have patterns attempt to reduce that complexity by being heavily weighted towards using encapsulation. Functional languages, by converse, are heavily weighted towards composability as the key feature to reducing complexity. A better mixture of both is needed to get better control over our UIs.

对于已经了解有关“四人模式”和“面向对象模式”的知识的任何人，但没有看过Rich Hickey的演讲“ Simple Made Easy”， 请立即观看 。 Hickey谈论的核心概念是太多的外部性是我们在阅读时不完全了解我们的代码在做什么的主要原因。 这并不容易，因为一次旋转的板太多。 面向对象的语言有一些模式试图通过高度重视使用封装来降低这种复杂性。 相反，功能语言非常重视可组合性，这是降低复杂性的关键特征。 为了更好地控制我们的用户界面，需要将两者更好地结合在一起。

Pure Views bring some of the benefits of functional languages to the OO world most developers live in. In functional languages, a pure function only does one thing and has no side-effects (side-effect meaning that it can’t affect anything, only return a new value). Multiple simple functions can be composed in different ways to produce many types of outputs. To paraphrase Rich Hickey; Simple means doing one thing. Easy means something we’re able to understand the extent of. In the case of Pure Views, looking the render function we should be able understand all the potential outputs. It reduces the need to understand the entire code base to know how it can effect a single function.

纯视图为大多数开发人员所居住的OO世界带来了功能语言的某些好处。在功能语言中，纯功能只能做一件事，并且没有副作用(副作用意味着它不能影响任何东西，仅返回一个新值)。 可以用不同的方式组合多个简单功能，以产生多种类型的输出。 释义Rich Hickey; 简单意味着要做一件事。 简单意味着我们能够理解其范围。 对于纯视图，通过查看渲染功能，我们应该能够理解所有潜在的输出。 它减少了理解整个代码库以了解如何影响单个功能的需要。

This is how functional, Pure Views process would work:

这是功能性的“纯视图”流程的工作方式：

This is an incredibly powerful concept. Instead of having to propagate through functions, events and network stacks and mutations everywhere, just take a snapshot of the data and render to a view. The view will have all the layout, event handlers and access points for the user to interact with the underlying data. This means to get to any location in the application, the only dependency is a static data model. Generally these Pure Views are coupled with lifecycle methods to better understand when, why and how the data changes. For example, take a look at some actual code of a Pure View:

这是一个非常强大的概念。 不必在各处传播功能，事件，网络堆栈和变异，而只需对数据快照并呈现为视图即可。 该视图将具有所有布局，事件处理程序和访问点，供用户与基础数据进行交互。 这意味着要到达应用程序中的任何位置，唯一的依赖关系就是静态数据模型。 通常，这些纯视图与生命周期方法结合使用，可以更好地了解数据何时，为什么以及如何发生变化。 例如，看一下Pure View的一些实际代码：

createView({  getDefaultProps(){    return {      selectedIds: [1, 10],      banks: [/* bank data here */]    };  }   render(){     let selectedBanks = this.props.banks.filter(function(bank){      return this.props.selectedIds.indexOf(bank.id) > -1;    });    let bankItems = [];    for (let i=0; i < selectedBanks.length; i++){      bankItems.push(        el("BankItem", {key:i, bank:selectedBanks[i]})      );    }    return el("div", null,             el("h1", null, "Selected Banks"),             bankItems,             el("a", {href:"/install", "Next")           );  }})

This view encapsulates properties that are passed in by it’s parent. When the render function is called, it doesn’t require anything outside of the view’s own scope. Everything that can affect the output is all in a single function. Until the render function is finished the props and state can not be changed either. This makes it easy to reason about what will happen on each run. Whenever the parent send it new data, it will trigger the render function to run again.

该视图封装了其父级传递的属性。 调用render函数时，它不需要视图自身范围之外的任何内容。 可以影响输出的所有内容都在一个函数中。 在渲染功能完成之前，道具和状态也无法更改。 这样就很容易推断出每次运行会发生什么。 每当父级向它发送新数据时，它将触发render函数再次运行。

扩展功能而不增加复杂性 (Expanding capabilities without adding complexity)

Because Pure Views do only one thing and don’t effect anything out their own scope, it makes it extremely flexible without introducing extra complexities. There’s a few cases that really show the power of Pure Views.

由于纯视图只做一件事，不会在自己的范围内影响任何事情，因此它在不引入额外复杂性的情况下具有极大的灵活性。 在某些情况下，确实可以显示Pure View的功能。

The first is called Hot Module Replacement. If you’re thinking this is just like Live Reloading in the browser, you’re way off. The instant you save a file in your editor, only the updated code can be sent to your app, replaces the old code, the render function for that view is ran and only the HTML that differs is changed. The entire data layer of the app is unaffected. This works with layouts, view hierarchies and event handlers. The data in the app doesn’t change so you’re view is updated in real time. There are libraries to support this in browsers, iOS, Android, Windows and Mac app. When the iteration time between making a change in the code and seeing the output is near 0, it completely changes your coding workflow.

第一个称为热模块更换 。 如果您认为这就像浏览器中的“实时重新加载”，那您就走了。 您在编辑器中保存文件的那一刻，只有更新的代码可以发送到您的应用程序，替换旧代码，该视图的渲染功能运行，并且仅更改了不同HTML。 应用程序的整个数据层不受影响。 这适用于布局，视图层次结构和事件处理程序。 该应用程序中的数据不会更改，因此您可以实时更新视图。 浏览器，iOS，Android，Windows和Mac应用程序中都有支持此功能的库。 当在更改代码与查看输出之间的迭代时间接近0时，它将完全改变您的编码工作流程。

The next is Time Travel Debugging. It’s really amazing as it sounds. Without Pure Views, storing every event propagation and it’s affects on the view is an impossible load for most systems. With Pure Views all that’s needed is to have an array and push a new copy of the data each time it’s changed. If you understand how persistent data structures work, it’s even less work to save every change in your app. When debugging, just scrub back and forth just like a VCR. (Yeah 80’s UI technology and most UI frameworks don’t have it in their debug toolkit today). Application state can even be serialized and saved on the server in production to get full repo steps of just about every bug in your app.

接下来是时间旅行调试 。 听起来确实很棒。 如果没有纯视图，则对于大多数系统来说，存储每个事件传播及其对视图的影响都是不可能的。 使用Pure View，所需要的只是拥有一个数组，并在每次更改时推送一个新的数据副本。 如果您了解持久性数据结构的工作原理，那么将所有更改保存在应用程序中的工作就更少了。 调试时，就像VCR一样来回擦洗。 (是的，80年代的UI技术和大多数UI框架今天在其调试工具包中都没有使用)。 应用程序状态甚至可以序列化并保存在生产环境中的服务器上，以获取有关您应用程序中几乎每个错误的完整回购步骤。

The last major capability is Resiliency Over Rigidity. The data is not tied to the UI. It’s clear separation of concerns. The data layer of your application can focus in terms of functions, data transforms and caching without having to think about all the concerns a user might have. On the vast majority of projects the business logic hardly changes; code for an comm shopping cart pretty much has the same requirements. But on the View layer, designers are always finding new ways to explain or clarify the interface or increase sales. Unit and integration tests can focus on testing the application flow in pure, simple data. Since the View is just a simple transform and a reflection of the data at any given state it’s much less susceptible to having complexities or bugs. This also means when the designer or business director asks for changes to the view, it can be done without affecting the functionality of the data flow.

最后一个主要功能是弹性之上的弹性 。 数据未绑定到UI。 显然是关注点分离。 您的应用程序的数据层可以专注于功能，数据转换和缓存，而无需考虑用户可能遇到的所有问题。 在绝大多数项目中，业务逻辑几乎不变。 comm购物车的代码几乎具有相同的要求。 但是在View层上，设计人员总是在寻找新的方法来解释或阐明界面或增加销量。 单元和集成测试可以专注于在纯净的简单数据中测试应用程序流。 由于View只是一个简单的转换，并且可以在任何给定状态下反映数据，因此不易出现复杂性或错误。 这也意味着，当设计人员或业务主管要求更改视图时，可以完成此操作而不会影响数据流的功能。

回到真实世界 (Back to the real-world)

The movement of Pure Views is growing. There’s few, if any benefits traditional view layers have over Pure Views. Framework that are more open like Backbone you could swap out string templating systems for Pure Views. More and more framework authors are seeing the advantages and moving to Pure Views. A few notable frameworks that are really championing this approach are Elm, Ember 2, Om Next, ReactJS.

Pure View的运动正在增长。 传统视图层相对于纯视图几乎没有好处。 像Backbone这样更加开放的框架，您可以将字符串模板系统换成Pure View。 越来越多的框架作者看到了优势，并转向纯视图。 一些真正支持这种方法的著名框架是Elm，Ember 2，Om Next，ReactJS。

To take advantage of some of the extended capabilities Pure Views offer there are some out-of-the-box tools that make it easier to integrate. For Hot Module Replacement, Webpack and React have a great setup. I maintain a starter kit called Megatome that should get you up and running on a new project in 2 minutes. For Time Travel Debugging look to Redux with is a data layer built to work with React.

为了利用某些扩展功能，Pure Views提供了一些开箱即用的工具，使集成更容易。 对于热模块更换，Webpack和React具有出色的设置。 我维护了一个名为Megatome的入门工具包，该工具包将使您在2分钟内启动并运行一个新项目。 对于Time Travel Debugging， 请看Redux with是一个可与React一起使用的数据层。

On last note is for all those who get stuck scrutinizing syntax (like Lisps or JSX): don’t judge a book by it’s cover. If you don’t look deeper, you can completely ignore the possibilities and power that can come from something different. Look again at the code above for a real-world Pure View above. It’s all valid code with no need for transpilation, package managers or any additional build steps. The only thing that’s missing is the top 3 lines:

最后要注意的是，对于那些陷入语法审查困境的人(例如Lisps或JSX)：不要凭封面判断一本书。 如果您不深入，则可以完全忽略其他事物带来的可能性和力量。 再次查看上面的代码，以获得上面的真实世界的Pure View。 所有这些都是有效的代码，无需编译，程序包管理器或任何其他构建步骤。 唯一缺少的是前三行：

let el = React.createElement;let createView = React.createClass;

My latest project is harder than coding. We’re making personal finance not suck. See how your spending pace leads to mastering your budget at getfiskal.com.

我最新的项目比编码难。 我们正在使个人理财不受影响。 在getfiskal.com上了解您的支出进度如何掌握预算。

翻译自: https://www.freecodecamp.org/news/the-revolution-of-pure-views-aed339db7da4/

纯函数式编程语言