My problem is with JavaScript in the browser but I guess it could apply to any event-driven environment.
I have coded up a widget in my app. The widget allows a user to select an item using 3 different sub-widgets (table, map & gallery). The sub-widgets display the same items and a selection can be made from whichever sub-widget the user prefers to use. Whenever a selection is made by the user or set in code a “selection-changed” event is fired by the sub-widget. The main widget listens for these “selection-changed” events.
This worked fine until I started getting further on with the project and realized that I needed to adjust the selection in the other 2 widgets when the selection changes (If the user selects an item on the map, it should highlight that same item in the table and gallery). The problem is that when I set the selection in the other 2 sub-widgets they in-turn fire the “selection-changed” event and that ends up getting pretty recursive. This also happens when I need to clear the selection in all of the sub-widgets (I get 3 “selection-changed” events with the same empty data). This leads to several redundant calls being made for external resources and gives me the feeling it will lead to further problems in future.
So my question is am I doing events right? The answer is obviously ‘no’ because I’ve got myself in to a pickle so early on but I wonder how other people use events without getting in to these problems – what kind of architecture would be better in this situation?
Maybe I could have a way of setting and clearing selections in the sub-widgets that doesn’t go on to fire the event but this feels like a hack and may end up conflicting with the framework I’m using to handle my views/models.
3
My preferred solution for this recursion problem (I have it a lot) is to have each action check to see if it really did something before triggering the next action. In this case, the first subwidget changes and notifies the superwidget, which, noting that its (the superwidget’s) condition really has changed, tells the other two subwidgets to change. Each widget that does need to change (some may already be set correctly) does so and notifies the superwidget. However, at this point the superwidget notices that the notifications haven’t changed its status, it therefore doesn’t tell anybody to do anything, and the recursion stops.
Otherwise I use Dan Pichelman’s two-event solution. It’s less elegant, but sometimes faster. But I usually prefer the elegant solution anyway–it works even in really complicated situations.
This is a common problem with an event system. There is one main central authority, which pushes the events from and to the listeners. It is pretty crude, but workable.
There is a small catch here. The system soon gets more complicated and the propagation of the events is more or less opaque. It is difficult to determine, what the system is actually doing. Also unwanted effects can creep in.
There are already two solutions given, which are fine solutions, but I also want to give a solution, which is a refinement on the event model.
Reactive programming
If you take a crude event system and you break it up in smaller parts, you will see there are several functionalities, which seems to be shared:
- Filtering of events
- Pushing events into the stream of events (which is a source of events)
- Acting onto the stream of events. (which is a sink of events)
- Manipulating the events in the stream (eg. mapping over them)
In reactive programming these components are separated and as you can see, it is possible to build the crude model from this. The key element is that you separate the input from the output.
With these components you can build a network and explicitly route your events through your application. This makes the working of your system more transparent and also adds a lot of flexibility. The cool thing about this, is that you can unify events from callbacks into the system.
A network looks typically like this:
clickbutton -> some switching -> change picture
app1-change --/ / ----> stopclock
clock_tick -----/ ----> start clock
An interesting in the concept of reactive programming is the following site: functional-reactive-programming-with-bacon-js/
In functional reactive programming, there are two thing which can propagate through your network. Behaviors, which are continuous signals. Think about the user mouse movement. And events, which discrete signals. This goes somewhat theoretical deeper waters than normal reactive programming.
2