// With events (using simpler on* properties)
// A couple of functions to save repetiton
function handleError(err) {
addTextToPage("Argh, broken: " + err.message);
hideSpinner();
}
function hideSpinner() {
document.querySelector('.spinner').style.display = 'none';
}
// In this example, we get an object we add load & error listeners to
var request = getJsonEvent('story.json');
request.onload = function() {
addHtmlToPage(request.response.heading);
// We need to track if anything failed
var errored = false;
// Track the next chapter that can appear on the page
var nextChapterToAdd = 0;
var chapterHtmls = [];
// We store chapter requests so we can remove listeners later
var chapterRequests = request.response.chapterUrls.map(function(chapterUrl, i) {
var request = getJsonEvent(chapterUrl);
request.onload = function() {
// Store this chapter, we might not be able to deal with it yet
chapterHtmls[i] = request.response.html;
// Try and add new chapters to the page, in order.
// Stop when we reach a chapter we've yet to download.
for (; nextChapterToAdd in chapterHtmls; nextChapterToAdd++) {
addHtmlToPage(chapterHtmls[nextChapterToAdd]);
// Did we just add the final chapter?
if (nextChapterToAdd == story.chapterUrls.length - 1) {
addTextToPage("All done");
hideSpinner();
}
}
};
request.onerror = function(event) {
// prevent further events
chapterRequests.forEach(function(request) {
request.onload = null;
request.onerror = null;
});
handleError(event.error);
};
return request;
});
};
request.onerror = function(event) {
handleError(event.error);
};
I don't know Jake … you almost convinced me then I've read the comparison by number of lines and spot many differences, declared functions, empty lines, etc etc … so here the eddy.js (a 2.2KB minzipped utility) version of your first Promises based example, still using events and bits of some smart trick you put in there.
@WebReflection @jakearchibald pretty simple in RxJS as well, for example:
just in case somebody else would like to "play" … the game here is the ability to render chapter 1, 2, and 3 at once then chapter 4 and 5 in a second "flush" considering a disordered reply chapters order such: 2, 5, 3, 1, 4
where 5 won't be rendered but 1,2,3 will after the 1 is complete, and 4,5 will be rendered after the 4 is complete.
Anything that just render all of them at once is not valid example
Anything that renders ASAP each chapter is not valid example
Accordingly, check your code before posting and show your magic ;-)
Why does the generator example have try/catch?
@rwaldron to catch errors :D
Rejected promises are thrown as errors. There's a section on this at http://www.html5rocks.com/en/tutorials/es6/promises/
@WebReflection love the technique of reusing the original array! However, you should include the handleError definition, and you need to stop the spinner on error/success.
Also, unless I've read it wrong, your error handler may get called multiple times if multiple chapters fail? You'll need something to prevent that.
@mattpodwysocki that's really nice. The plain promises example loses out because there's a lack of "map" or similar, which is a shame because I don't think the reduce stuff is awfully friendly.
Is your error message going to be displayed once at most, even if multiple chapters fail? Also, you need to hide the spinner on error/success.
If we're going for brevity, here's the generators example:
Just to expand on the rules laid down by @webreflection:
getJson('story.json')to fetch story.json in json format - if this returns a promise/observable whatever, state what it returns & what libraries you need to return itheadingproperty, add it to the page withaddHtmlToPagechapterUrlsproperty, an array of urls. Fetch each chapter as json thenaddHtmlToPage(responseJson.html)document.querySelector('.spinner').style.display = 'none';@jakearchibald the error and finalization are only called at a maximum once. The nice thing is that we can add a
retry(3)to each one to ensure that we retry if there are failures per chapter, else provide a default answer if it still continues to fail,.updated accordingly with rules … well, it might be more beautiful despite the amount of lines … very readable, much wow :D
Nice, fun exercise. I enjoyed the challenge. :)
I'm including here my two answers, using asynquence, which is a 1.1k minzipped abstraction on top of promises. BTW, I didn't go for least-number-of-LoC, I wanted most-readable form, so I factored out many of the inline anonymous functions to named functions.
The boiler-plate:
The first solution uses asynquence almost identically to the first promises example above. While some don't like
map/reduce, I actually think they're quite helpful for readability here.The second solution sets up both an iterable
renderingsequence and a separate sequence for the chapter loading. This second loading sequence controls the iteration (vianext()) of therenderingsequence, executing each step at the appropriate time. Depending on how you think about the task, I think this code is cleaner (though a little longer) because it separates the concerns of loading from rendering.Note: Thisiterablesyntax for asynquence is an upcoming feature addition to the library which should be available shortly. See Issue #4 for more information about the adding ofiterable()support.Update: Iterable Sequences are now in asynquence, and work as shown above!
Update:
Realized another way to do the promises-style example, without needing reduce, but instead another
map(..)call, plusapply(..). This feels a bit more readable IMO:Here's how it works:
getJson("story.json")fires off a request to get the JSON for the story.seq(function(story){...runs, wherestoryis the JSON object.addHtmlToPage(story.heading)renders the story heading to the page.story.chapterUrlsis an array of strings (URLs).story.chapterUrls.map(getJson)callsgetJson()for each URL string in the original array, which produces a new array of loading sequences, one for each chapter URL.story.chapterUrls.map(getJson).map(waitForChapter)callswaitForChapter()for each loading-chapter sequence, which returns a function that will generate a new sequence which listens for each chapter loading sequence to finish and then callsrenderChapter()to render that newly loaded chapter. The result of this secondmap(..)call is yet another new array, a series of functions which, when called, each produce a load-and-render sequence for each chapter.ASQ().seq.apply(null, ... )takes this array of functions andapplys it toASQ.seq(), which chains each chapter load-and-render sequence as sequential steps in this main sequence. So each chapter sequence will, when the previous chapter finishes rendering, check to see if the next chapter is loaded, and if so, render the it, otherwise will keep waiting.The end-result of this map/map/apply trick is basically the same as: