Confusing

[Raynos]

What's the difference between

• EventEmitter
• Event
• Watchable
• Signal

[Gozala]

What's the difference between

• EventEmitter

This one is node construct that complects several different constructs into one thing. Which is like an Event with multiple channels and special channel for errors & no guarantees that same listener can't be registered more then ones.

• Event

I have being studying papers about FRP and event and concise description of it what readme states. I can either discuss more broadly in person or you could take a look at prior art

• Watchable

It' actually Watchables (watchable was taken :) and it's an abstraction or interface if you like that defines API that can be applied to different things. For example Eventuals implement this abstraction.

• Signal

This is part of signal refactoring actually again based on FRP papers. Signal is like Event but you can not dispatch on it. It can be created of event or implemented from ground up similar to dom-reduce. Also it looks like signals only notify watchers when value has changed, so for example if it's made of event that dispatches same value several times in a row signal will trigger only once when value has changed. Fills like it's better feet for what we're doing in reflex. I plan on factoring Signals out of the reducers and channels will probably just go away.

[Gozala]

Overall idea is to make small composable building blocks instead of things that solve different problems in one construct. That being said I'm not sure if I'll settle down on this solution or if I'll just revert back to what we already have.

[Gozala]

One more important detail is that in FRP events and signals don't have notion of end which reducers do expect.
I believe this is still composable though as reducers just treat error types values as errors and reject reductions over
such streams as broken with that error. Similarly end of collection / stream is just a special value that reducers understand as an end of collection and stop a reduction. I think making events and signals unaware of end or error binds into this very well similar to how array-s have no notion of error or end it's just if the they contain one of these reduction behaves as described above. This separation of concerns will greatly simplify implementation too.

[Gozala]

Well array actually do have notion of end but in a different way. For reducers [a, b, end, c, d] is equivalent of
[a, b].

[Raynos]

I still don't understand how signal and event are different other then minor implementation details.

[Raynos]

Also when referencing FRP make sure to distinquish between FRP signals / behaviours and "reducers/signal"

[Raynos]

It's also important to distinguish between signals which are a continuous representation of data over time (as continuous as the implementation allows) and events which are discrete and occur at certain moments in time.

i.e. an FRP signal is will have a value at t1 and t1 + delta even if those values are the same. An event occurs at t1 and (maybe) t2, and event does not need to have a meaningful value at t1 + delta.

(I may be full of shit but that's how I interpret the difference between signal and event)