OK, I think I got it - but want to double-check if I'm thinking about this right.
In other event-driven architectures, listen()
is typically the starting point for processing. An event comes in and you operate on it, transform it, use it for side effects, pass it around, etc.
In FRP, listen()
is the endpoint. An event comes in and it inherently flows through the frp graph which does all the pure (side-effect free) processing, and then at the end of that pipeline - you use the final result in some way (e.g. for side effects). In this sense it might be helpful to think of listen()
as listening to part of the graph (rather than listening to a particular event) or- perhaps even output()/gotResult()
. It is analogous to tap()
in some FP JS frameworks. This begs the question, "so what's the starting point?" - and while it's tempting to say send(), which is true, if we say listen() is the starting point for processing in event-based architectures, the starting point in frp is the graph which is setup to process the events (which get fed into a listen() at the end).
Visualizing the graph as a whole to be the starting point takes a bit of a mental leap - since it's composed of structures (transactions) that are above time. It may help to think of it like a circuit - while current may be introduced at a certain place and time - and there is a specific controlled order to where and how it flows over time, getting the results you need is more about where to place interfaces to the outside world rather than when some particular electron will reach there vs. another place- and where to place those interfaces is nearly always at the conceptual end when the electricity has been processed and is ready to leave the circuit to have some affect on the surrounding world.
Is this accurate? If so, any nuance that can be clarified better?