Using Deferred Objects to Counter Threading Problems
init, but if it shows up early then it will ask for things that don’t exist yet. That’s bad.
Even worse, it will still be a problem when we decide whether to gather all of the code into three files or four or however many. They could possibly load out of order instead of in sequence as the HTML would imply. This looked like a job for Deferred Objects.
Before we go further, let me explain the basic structure of our codebase. We have a bunch of files which create an object inside an closure function and then return it. The result is that a parent object is created with a bunch of methods. Each one leaves the main object alone if it exists, but creates one if it doesn’t.
At this point, it doesn’t matter which one loads first, second or whatever. We can concatenate in any order and split things up any way we like. The only hard rule is that the final init command is executed last, after all of the files are loaded and run.
Here’s a snippet to give you an idea of what the modules look like. There could be a bunch of these, as well as a parent controller module.
After all of that happens and all sorts of groovy modules are added to a central global object, we’re supposed to fire an
init function in the primary parent module. This function will have code which will check for the existence of the various modules and fire
This must go last, but… thanks to the wonders of threading, it tends to go first. And if we concatenate that sucker into one of three files, we still don’t know which will fire first. What to do?
Well, it occurred to me that we could take advantage of loading jQuery in the
head. I wanted it in the footer, but Mura does stuff in the middle of the page and jQuery needs to be present. Therefore, we can put a script tag into the head where we declare some deferred objects. The logic pattern is in this fiddle. Check out the comments in that and then come back. I’ll wait.
We apply this logical goodness by declaring the deferred objects and the array in the head, along with the
I added three files to the mix. Each of them contains just one line, which resolves one of our deferred objects. When Gulp concatenates things, it adds that line to the end of each of the output files. Three deferred objects for three files, and each one resolves when the file is completely loaded and run. Once they’re all in, the final
done function runs and our primary
init function is called.
So it doesn’t matter which file runs first because they’re designed to make functions available without running them until their inits are called, and their inits aren’t called until everything is loaded. Yay!