0

I'm trying to save user content on blur and am encountering a weird UI freeze after the save that I've never seen before.

A simplified version of the template:

{{#each UserSession.getQuestions}}
   <textearea class='question'>{{UserSession.getVal this._id}}</teaxtarea>
{{/each}}

In other words, we iterate over a cursor from the Questions collection that selects all questions a user must answer, and we populate the textarea with a value from the UserSessions collection that contains this user's response to that question. For what it's worth, the textarea is actually in its own template (there are other things to show in there so i figured best to keep them isolated).

The user can modify the content of his response, and then I have an event handler that basically does this:

"blur .question": function(e) {
   var val = $(e.target).val();
   var questionId = this._id;
   var userSessionId = Meteor.user().getSessionId();
   var modifier = {$set: {}};
   modifier["$set"]["questions." + questionId + "] = val;
   UserSessions.update({_id: userSessionId}, modifier);
}

The update succeeds but the browser freezes for about a second after the save executes, so that if the blur is triggered by a user clicking on another element, that element doesn't come into focus cleanly. This is a problem because I also want to do periodic saves while the user is typing, but when I do that, the hiccup interrupts the typing: the resulting experience is pretty brutal.

The interesting thing is that the browser only seems to freeze when the property being updated is an object or in a list. In other words:

UserSessions.update({_id: userSessionId}, {$set: {"questions.questionId": "someVal"}}) causes the freeze, as does UserSessions.update({_id: userSessionId}, {$set: {"lastSavedAt": new Date()}}).

However, UserSessions.update({_id: userSessionId}, {$set: {"someOtherProp": "someVal"}}) works fine.

I've tried several different approaches, including an async client-side pattern and executing the save via Meteor Method in a if (Meteor.isServer) block -- all the same result. Must be something to do with the publication updating, but it happens even when i set the publish function query to {reactive: false}.

I'm out of ideas. Your help, as always, is greatly appreciated.

Thanks in advance, db

Daniel Bernhard
  • 382
  • 3
  • 11

1 Answers1

0

Ok I think I figured it out. For anyone else who has this problem, if you're using Iron Router you should check it for un-necessary dependencies. In this case it was the router being re-run that clogged up the works, because the data hook included a reactive find request on the UserSessions collection. I set reactive to false and specified the fields to prevent a recomputation, and everything smoothed itself out.

Daniel Bernhard
  • 382
  • 3
  • 11