Pattern that prevents events to trigger themselves

Question

I am working at the client-side part of a web application, that is responsible for getting answers from users for specific questions and storing and restoring them from the database (or cookies) and I am running into the issue that updating the answers from the db will also trigger saving them again (because the same method answerQuestion is called).

Here's a simplification of my use-case (coffeescript):

class Questionnaire
  constructor: ->
    @prefillAnswers()
    @listenToInput()
    @listenToQuestionChanges()

  prefillAnswers: ->
    for q in @questionNames
      @answerQuestion getAnswer(q)

  listenToInput: ->
    $('.input').on 'change', (e) =>
      $input = $(e.currentTarget)
      @answerQuestion $input.data('questionName'), $input.val()

  listenToQuestionChanges: ->
    @subscribeToEvent 'answeredQuestion', (msg, data) =>
      saveAnswer(data.question, data.answer)

  getAnswer: (qName) ->
    # fetches answer from a database (such as cookies, but is irrelevant)

  saveAnswer: (qName, answer) ->
    # saves the answer

  answerQuestion: (qName, answer) ->
    @publishEvent 'answeredQuestion', {question: qName, answer: answer} # This part triggers unnecessary saving, but where is the best place for this?
    # Change state of UI and data "model"
    # ...

My question is, is there an OOP pattern that discusses this issue and possible solutions? I don't know how to start addressing this, and reading an entire book is not an option right now (I however have it on my todo list).

Perhaps this could be rewritten with a MVC pattern, and I'm moving towards that by starting to read the book JavaScript Web Applications, but can't see right now even with MVC, how my problem is avoided in the best way...

Neil · Accepted Answer · 2014-07-28T16:27:36.357

The problem lies with the concept of answerQuestion. You use answerQuestion for two roles:

User input provided, listeners perform appropriate actions.
Server update provided, listeners perform appropriate actions.

Simple approach

While they are similar, they are not the same. The pattern for this (if you want to call it that), would be to have two separate methods. The first method deals with triggering listeners, while the second should send the request to the server to save.

In this way, for scenario #1 when user provides input, you call not only the trigger method but also the save method (explicit call). This way, when you receive a server update, you can simply call the trigger to update the page, without creating a second request.

Dirty flag

Another approach could be to use the concept of a dirty flag, which does nothing more than let your client know that it has changed with respect to the server's version. Rather than use two separate methods, your answerQuestion will only perform the trigger. A listener will check the dirty flag status, and if it has been changed, it will send update request to the server. It should go without saying that all information coming from the server at that point will have its dirty flag set to false, and so even though your listener receives the event, it will see that no changes have been made and ignore it.

Event flags

Listeners should not generally care about the origin of the event in order to be truly decoupled, however you could provide event information in the form of a parameter in order to make a distinction based on who triggered it. However, you may have to check multiple sources this way, so it may be preferable to simply use a boolean value indicating whether or not it is user input or triggered by the user in some way. If another event is triggered as a consequence, that event too would maintain the same value for this flag since it too is (or is not) ultimately caused by a user.

Conclusion

While the dirty flag is better for larger projects, I wouldn't recommend it unless you find yourself having to repeat yourself several times for several different objects (thus becoming unreadable). Event flags may fit you better if you prefer event-driven architecture rather than object-oriented like the dirty flag approach.

I hope that helps.

I like the simple approach, however the problem is that I wanted my system to be flexible enough to use a pub/sub system to handle events so any other code can subscribe to the `answeredQuestion` event, no matter if input is from server or user. Wondering if there's a way to avoid the coupling that comes with it but still allow for this kind of flexibility. The dirty flag approach seems a bit clunky and anti-MVC in a way or am I wrong? — Cristian, Jul 28 '14 at 13:53
I'm just thinking, that in MVC, you update the model and the changes reflect in the UI. But what when you update the model through the UI, then do the changes reflect 2 times in the UI? Or how do popular JS MVC frameworks work? — Cristian, Jul 28 '14 at 13:56
@Cristian You generally apply an event once for each time it happens. Listeners shouldn't care about whether or not it comes from the server or from the user. If that is an issue, you should also provide event information specifying the source of the event. I'll add that a possibility on my answer. — Neil, Jul 28 '14 at 16:22

Pattern that prevents events to trigger themselves

1 Answers1

Simple approach

Dirty flag

Event flags

Conclusion