[SOLVED] This.unblock() vs async vs Meteor.defer()

help
22

In terms of defer, this is how we normally use Meteor.defer() in our projects:

run (inputs) {
  const results = processToGetResultsFromInputs(inputs);
  
  // closure with access to inputs and results
  Meteor.defer(processInputsNotRequiredToGetResults());

  return { results }
}
1 Like
23

Cool, I could see how that would be helpful!

24

Thanks everyone for your feedback and discussion, it was helpful.

So my takeaway from this discussion is:

1. this.unblock() and async are interchangeable.
(I personally prefer async because I find it more clear on what is going on)

2. Meteor.defer() is designed to wrap a piece of code inside of a method that you don’t need to wait on (like sending an email)

7 Likes
25

I beleive it was designed this way because Meteor was designed to work with an optimistic UI out of the box.

Optimistic UI needs db queries to be done in order because the client updates immediately, before the server has started/finished processing a request.
You can imagine a situation where you create an object and then start editing updating it right away with optimistic UI. Now without a method queue if the create action takes much longer for some reason, it’s possible that the update will get processed first and fail because it depends on the result of the first request. With a queue, it guarantees that the server processes action in the same order in which the client performed them, eliminating a whole class of state / timing bugs.

Optimisitic UI also means that the extra wait for processing requests in a queue has less impact on the user, as they can continue working with the simulated results while the server is catching up

It does make me wonder why they made async functions unblock by default

3 Likes
26

Thank all of you. Informative and useful. I’ve been looking for an such information :+1: :+1: