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…
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.
3