函数响应式编程相对于事件监听器的优势

问题描述

我听说过很多关于函数式反应式编程的内容，并决定看看有什么大不了的.通过 bacon.js 文档，似乎主要区别在于，我没有在组件上设置事件侦听器，而是在其上创建事件流，并将事件处理程序传递到流中.换句话说，我真正做的只是将事件处理程序从组件移动到事件流.是这样吗?如果是这样，这样做的最大优势是什么?

I've been hearing a lot about functional reactive programming, and decided to check out what the big deal is. Going through the bacon.js documentation, it seems that the main difference is that instead of setting an event listener on a component, I create an event stream on it, and pass the event handler into the stream instead. In other words, all I really did was move the event handler from the component to the event stream. Is that it? If so, what's the big advantage of doing this?

推荐答案

是吗?

没有.这是关于拥有事件流.最后你仍然会为它们附加监听器来执行效果，但是在源和目标之间你有一个非常强大的抽象.

No. It's about having event streams. You still will attach listener to them in the end to execute effects, but between the source and the destination you've got a very mighty abstraction.

这样做有什么好处?

事件流确实有很多 高阶函数来轻松处理它们，并在不写出所有容易出错的样板代码的情况下编写它们.

The event streams do have lots of higher-order functions to easily deal with them, and for composing them without writing out all the error-prone boilerplate code.

正如文档所说的非常好，培根

通过从命令式切换到函数式，将您的活动意大利面变成干净和声明式风水培根.这就像用 map 和 filter 等函数式编程概念替换嵌套的 for 循环.停止处理单个事件并改为使用事件流.将您的数据与 merge 和 combine 相结合 [并使用] 更重的武器 [例如] flatMap 和 combineTemplate..p>

turns your event spaghetti into clean and declarative feng shui bacon, by switching from imperative to functional. It's like replacing nested for-loops with functional programming concepts like map and filter. Stop working on individual events and work with event streams instead. Combine your data with merge and combine [and wield] heavier weapons [like] flatMap and combineTemplate.

这篇关于函数响应式编程相对于事件监听器的优势的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！