But wrapping execution of the operation function and recursive call in a setImmediate will allow the EventLoop itself handle the scheduling. It seems rather bad practice to try to control scheduling of the EventLoop within the application layer.
In the end, the exercise was to write non-blocking code. Even if the callback only fires once, before the EventLoop schedules the interrupt, then the test should pass because the goal of the exercise was accomplished (learn how to release control to the EventLoop).
The solution does sets an odd, arbitrary threshold for releasing control to the event loop:
https://github.com/timoxley/functional-javascript-workshop/blob/master/exercises/blocking_event_loop/solution/solution.js#L6-L9
This arbitrary assumption is coded into the test runner for this exercise, tightly coupling the two: https://github.com/timoxley/functional-javascript-workshop/blob/master/exercises/blocking_event_loop/wrapper.js#L34-L37
But wrapping execution of the
operationfunction and recursive call in asetImmediatewill allow the EventLoop itself handle the scheduling. It seems rather bad practice to try to control scheduling of the EventLoop within the application layer.https://repl.it/@RavenHursT/Functional-JS-Workshop-Exercise-13-Solution
In the end, the exercise was to write non-blocking code. Even if the callback only fires once, before the EventLoop schedules the interrupt, then the test should pass because the goal of the exercise was accomplished (learn how to release control to the EventLoop).
For further reference: https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/