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.

  • 2
    You may need two events - selection changed by user and selection changed by program. Aug 13, 2013 at 13:49
  • @DanPichelman That's probably what I would do but the framework I'm using for the table doesn't allow me to tell the difference between the two so I was hoping that wasn't the answer. I could maybe set a flag before I set the table selection in code then check for that flag when the event fires but that feels really hacky. Hmm Aug 13, 2013 at 13:58
  • 1
    It would help if you focused your question more. What is the specific behavior your are trying to eliminate? What are the obvious solutions not available to you because of the framework you use? Aug 13, 2013 at 14:25

2 Answers 2


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.

  • 1
    I really like this answer and will definitely research these ideas further. I marked the other answer as accepted because it solved the specific problem I was having whereas this is more like a good idea for starting a new project. Thank you. Aug 21, 2013 at 7:23
  • No problem :) I understand that the other is more fit to your original answer, but I thought this would be interesting. Aug 21, 2013 at 10:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.