我正在学习响应式(Reactive)香蕉。为了理解该库,我决定实现一个虚拟应用程序,每当有人按下按钮时,该应用程序就会增加计数器。
我使用的 UI 库是 Gtk,但这与解释无关。
这是我提出的非常简单的实现:
import Graphics.UI.Gtk
import Reactive.Banana
import Reactive.Banana.Frameworks
makeNetworkDescription addEvent = do
eClick <- fromAddHandler addEvent
reactimate $ (putStrLn . show) <$> (accumE 0 ((+1) <$ eClick))
main :: IO ()
main = do
(addHandler, fireEvent) <- newAddHandler
initGUI
network <- compile $ makeNetworkDescription addHandler
actuate network
window <- windowNew
button <- buttonNew
set window [ containerBorderWidth := 10, containerChild := button ]
set button [ buttonLabel := "Add One" ]
onClicked button $ fireEvent ()
onDestroy window mainQuit
widgetShowAll window
mainGUI
这只是将结果转储到 shell 中。我想出了这个解决方案阅读 article作者:海因里希·阿普费尔姆斯。请注意,在我的示例中,我没有使用单个 Behavior
.
文章中有一个网络示例:
makeNetworkDescription addKeyEvent = do
eKey <- fromAddHandler addKeyEvent
let
eOctaveChange = filterMapJust getOctaveChange eKey
bOctave = accumB 3 (changeOctave <$> eOctaveChange)
ePitch = filterMapJust (`lookup` charPitches) eKey
bPitch = stepper PC ePitch
bNote = Note <$> bOctave <*> bPitch
eNoteChanged <- changes bNote
reactimate' $ fmap (\n -> putStrLn ("Now playing " ++ show n))
<$> eNoteChanged
示例显示 stepper
改变 Event
进入Behavior
并带回 Event
使用changes
。在上面的例子中,我们可以只使用 Event
我想这不会有什么区别(除非我不明白某些事情)。
有人可以阐明何时使用 Behavior
为什么?我们是否应该全部转换 Event
尽快吗?
在我的小实验中,我看不到 Behavior
在哪里可以使用。
谢谢
最佳答案
每当 FRP 网络在 Reactive Banana 中“做某事”时,都是因为它对某些输入事件使用react。它在系统外部执行任何可观察到的操作的唯一方法是连接外部系统以对其生成的事件使用react(使用reactimate
)。
因此,如果您所做的只是通过生成输出事件来立即对输入事件使用react,那么不,您不会找到太多使用Behaviour
的理由。
Behaviour
对于生成依赖于多个事件流的程序行为非常有用,您必须记住事件发生在不同时间。
事件
已发生;它具有值(value)的特定时刻。 行为
在所有时间点都有一个值,没有特殊的时刻(除了更改
,这很方便,但有点破坏模型)。
许多 GUI 都熟悉的一个简单示例是,如果我想对鼠标单击使用react,并让 Shift 键单击执行与未按住 Shift 键时单击不同的操作。通过 Behaviour
保存一个指示是否按住 Shift 键的值,这是微不足道的。如果我只有用于 Shift 键按下/释放和鼠标单击的事件
,那就困难得多。
除了更难之外,它的级别也更低。为什么我必须做复杂的摆弄才能实现像 Shift-Click 这样的简单概念? Behaviour
和 Event
之间的选择是一个有用的抽象,有助于以更接近您外部思考方式的方式实现程序的概念编程世界。
这里的一个例子是游戏世界中的可移动物体。我可以有一个事件位置
来表示它移动的所有时间。或者我可以只使用一个代表其始终所在位置的Behaviour Position
。通常我会认为对象始终拥有一个位置,因此行为
是一个更好的概念契合。
行为的另一个有用之处是表示您的程序可以进行的外部观察,您只能检查“当前”值(因为发生更改时外部系统不会通知您) .
举个例子,假设您的程序必须密切关注温度传感器,并避免在温度过高时启 Action 业。通过事件温度
,我将预先决定轮询温度传感器的频率(或响应什么)。然后遇到与我的其他示例中相同的问题,即必须手动执行某些操作以使最后的温度读数可供决定是否开始工作的事件使用。或者我可以使用 fromPoll
来制作行为温度
。现在我得到了一个代表温度随时间变化的值的值,并且我已经完全摆脱了对传感器的轮询; Reactive Banana 本身会根据需要尽可能频繁地轮询传感器,而我根本不需要为此添加任何逻辑!
关于haskell - 为什么我们要在FRP中使用Behavior,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26785025/