Reorganise the requestAnimationFrame loop to handle errors correctly

Since 413dac94b396b6b55da94ace6cd8efd9b43c1d12 errors are no longer
caught by default, which is a good thing for exposing user errors.
However, the current structure of the main fastdom loop means that a
single user error will mean that the loop will never be run again, so
jobs will continue to be added to the framelist but never processed.

This reworks the main loop to handle fastdom tasks first, ensuring a
consistent and robust state, and then running the user code where it
can error safely.

1 files changed, 12 insertions, 5 deletions

diff --git a/index.js b/index.js
index 32f1693..0e8f48f 100644
--- a/index.js
+++ b/index.js
@@ -333,17 +333,24 @@
     raf(function frame() {
       var fn = self.frames.shift();
 
-      // Run the frame
-      if (fn) fn();
-
       // If no more frames,
       // stop looping
       if (!self.frames.length) {
         self.looping = false;
-        return;
+
+      // Otherwise, schedule the
+      // next frame
+      } else {
+        raf(frame);
       }
 
-      raf(frame);
+      // Run the frame.  Note that
+      // this may throw an error
+      // in user code, but all
+      // fastdom tasks are dealt
+      // with already so the code
+      // will continue to iterate
+      if (fn) fn();
     });
 
     this.looping = true;