3 ms·
I don't know anything about Elm subscriptions yet. But there is a lot more to this stuff then just event emitters. Things like: * When an event/action/etc com
by jlongster 10y ago
I don't know anything about Elm subscriptions yet. But there is a lot more to this stuff then just event emitters.
Things like:
* When an event/action/etc comes through, does it always call listeners synchronously? Can you change that and schedule events manually?
* How do you compose subscriptions/event handlers? This is usually the hardest part, and where simple event emitters really start breaking
* What about the lifecycle of the listener? What happens when it subscribes or unsubscribes? More importantly, what happens when the source that it subscribed to "shuts down"?
All of these things get pretty complicated and is the reason why various fields like FRP exist. Simple event emitters work immediately, yes, but they are a pretty terrible abstraction to build an app on.
- smrtinsert 10y agoYeah the same questions popped up in my head. The natural end point to me looks more like Rx. Lifecycle and especially composition seem like big missing pieces.
- Matthias247 10y agoExactly these questions also came to my mind when I read the article. Subscriptions can get very tricky. Sometimes you want events to be synchronously fired, sometimes it's better when they are deferred into another eventloop tick. Unsubscription can also get quite tricky as you said. I really wonder if Elm got a generic solution that fits all possible usage scenarios.
- dreamdu5t 10y agoIt looks like Subscriptions are just Signals with another name. I don't see any difference except that functions like map, foldp, etc. have been removed to discourage first-order use of them.