wilsonpage / fastdom

Eliminates layout thrashing by batching DOM measurement and mutation tasks
6.83k stars 240 forks source link

Reorganise the requestAnimationFrame loop to handle errors correctly #36

Closed rowanbeentje closed 10 years ago

rowanbeentje commented 10 years ago

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.

rowanbeentje commented 10 years ago

@wilsonpage I would love to be able to add a test for this, ensuring that an error thrown in an early defer() doesn't block the execution of later defers in the queue. But I don't know how to catch an asynchronous error in mocha/phantomjs - let's discuss tomorrow if you know a way...

wilsonpage commented 10 years ago

This is great stuff! Can't wait to talk it over in t'office :)

wilsonpage commented 10 years ago

This must explain what we were seeing in iOS yesterday?