Unit 3 - Practice Quiz

In JavaScript, a new function execution context is created and pushed onto the execution stack every time a function is called. This context contains information about the function's variables, arguments, and scope.

The scope chain is a list of all the scopes (variable objects) that are accessible from the current execution context. When JavaScript looks for a variable, it searches up this chain, from the current scope to the outer scopes, until it finds the variable or reaches the global scope.

A closure is the combination of a function and the lexical environment within which that function was declared. It gives an inner function access to its outer function's variables and parameters.

The inner function forms a closure over the scope of the outer function, allowing it to remember and access the outerVar variable even after outer has finished executing.

JavaScript uses prototypal inheritance. Every object has a private property which holds a link to another object called its prototype. That prototype object has a prototype of its own, and so on, forming a prototype chain.

The prototype chain ends when a prototype is null. The Object.prototype is the base prototype for most objects, and its own internal prototype is null.

All JavaScript arrays inherit from Array.prototype. By adding a new property or method to this prototype object, you make it available to all instances of arrays through the prototype chain.

The Event Loop's job is to check if the call stack is empty. If it is, it takes the first event from the queue (like a setTimeout callback) and pushes it onto the call stack to be executed, enabling non-blocking asynchronous behavior.

Being single-threaded means JavaScript has only one call stack and can execute one piece of code (one function) at a time. Asynchronous operations are handled by the environment (like a browser) and the event loop, not by multiple threads in JavaScript itself.

A Promise starts in the pending state. It can then transition to either the fulfilled state (representing a successful completion) or the rejected state (representing a failure).

The .then(onFulfilled, onRejected) method is used to handle the outcome of a Promise. The first argument is a function that runs if the promise is fulfilled (successful).

The async keyword ensures that the function will return a Promise. If the function returns a value, the Promise will be resolved with that value. If the function throws an error, the Promise will be rejected.

Macrotasks include events like setTimeout, setInterval, I/O operations, and UI rendering. Promise callbacks are handled as microtasks.

The event loop has a specific order of operations. After the main script (a macrotask) finishes, it will process all available tasks in the microtask queue until it's empty. Only then will it move on to the next macrotask.

const is used to declare a block-scoped variable that must be initialized at the time of declaration and cannot be reassigned. It stands for 'constant'.

Template literals, defined by backticks (`), provide an easier syntax for string interpolation (embedding variables with ${...}) and creating strings that span multiple lines without needing to use \n.

A major feature of arrow functions is that they lexically bind the this value, meaning this refers to the context of the enclosing scope, unlike regular functions which have their own this binding.

The export keyword is used in a module to explicitly mark variables, functions, or classes that you want to be accessible from other modules that import it.

When importing a default export, you do not use curly braces {}. You simply provide a name (which can be anything, but is typically the same as the function/variable name) for the imported default value.

This is the core definition of a closure. It's a function bundled with its lexical environment, allowing it to 'remember' the variables from its containing scope.

The function inner forms a closure over the scope of outer. When innerFunc is called, it looks for the variable x in its immediate scope first. Not finding it, it looks up the scope chain to the outer function's execution context, where x is defined as 20. The global variable x is shadowed by the x in outer's scope. The line x = 30; modifies the global x, which does not affect the x captured by the closure.

The let keyword creates a new block-scoped binding for i in each iteration of the loop. Each setTimeout callback creates a closure that captures the value of i for that specific iteration (0, 1, and 2 respectively). When the callbacks execute after the loop has finished, they log the values they captured. If var were used, there would be only one i variable for the entire function scope, and all callbacks would reference the final value of i, which would be 3.

Each call to createCounter() creates a new, independent execution context and its own count variable. counter1 and counter2 each have a closure over a separate count. counter1.increment() is called twice, so its private count becomes 2. counter2.increment() is called once, so its private count becomes 1. They do not share the same state.

Since var is function-scoped, there is only one i variable that is shared across all loop iterations and all three function closures. The for loop completes before any of the functions inside myFuncs are called. By the time the loop finishes, the value of i is 3. When myFuncs[0](), myFuncs[1](), and myFuncs[2]() are executed, they all access the same i variable from their shared outer scope, which holds the value 3.

The hasOwnProperty() method checks if a property exists directly on an object instance and not on its prototype chain. The name property is set directly on the dog instance within the Animal constructor (this.name = name), so dog.hasOwnProperty('name') returns true. The speak method exists on Animal.prototype, not on the dog instance itself. Therefore, dog.hasOwnProperty('speak') returns false.

The prototype chain in JavaScript is 'live'. When a property on an object is accessed, the JavaScript engine traverses the prototype chain at that moment. Even though merlin was instantiated before castSpell was added to Wizard.prototype, the lookup for merlin.castSpell() happens after the prototype has been modified. The engine finds castSpell on Wizard.prototype via merlin's prototype link and executes it successfully.

1. car.__proto__ points to Vehicle.prototype, not Vehicle. 2. Vehicle.prototype is an object that serves as the prototype for instances, it is not the instance car itself. 3. car does not have its own constructor property, so it looks up the prototype chain to Vehicle.prototype. Vehicle.prototype.constructor points back to the Vehicle function itself. Therefore, car.constructor resolves to the Vehicle function.

The JavaScript event loop processes the call stack first, then the microtask queue, and finally the macrotask queue.

1. console.log('A') is synchronous and executes immediately.
2. setTimeout is a Web API. Its callback () => console.log('B') is placed in the Macrotask (or Task) Queue. Even with a 0ms delay, it must wait for the current call stack to clear.
3. console.log('C') is synchronous and executes immediately.
4. After the main script finishes and the call stack is empty, the event loop picks the first task from the Macrotask Queue, which is the setTimeout callback, and 'B' is logged.

The browser's event loop is responsible for more than just executing JavaScript. It also handles UI rendering. A typical event loop iteration involves: 1) Taking a task from a macrotask queue and executing it. 2) Executing all tasks in the microtask queue until it's empty. 3) Performing rendering updates if necessary (style calculation, layout, paint). This rendering step happens after the current script/task has finished, allowing the browser to update the display before starting the next macrotask.

A .then() handler that does not have an explicit return statement implicitly returns undefined.

1. The second .then() block receives 2 but returns undefined.
2. The third .then() block receives undefined as its val and logs it. It then attempts to return undefined + 1, which evaluates to NaN (Not a Number).
3. The final .then() block receives NaN as its val and logs it.

Promise.all is 'fail-fast'. It waits for all promises in the provided iterable to resolve. However, if any single promise rejects, the Promise.all as a whole immediately rejects with the reason of that first rejecting promise. It does not wait for the other promises to complete. Here, p2 rejects after 100ms, causing the entire Promise.all to enter the .catch block.

1. The await keyword pauses the function until the promise is settled. Here, the promise rejects, so control immediately jumps to the catch block.
2. The catch block determines that the function will return the string 'Caught: API Down'.
3. Crucially, the finally block is executed before the function officially returns a settled (in this case, resolved) promise. Thus, 'Fetch attempt finished.' is logged first.
4. After the finally block completes, the promise returned by fetchData() resolves with the value from the catch block.
5. The .then(console.log) handler receives this resolved value and logs 'Caught: API Down'.

The event loop has a strict order of operations:

1. All synchronous code in the current call stack is executed. This logs 'Start' and 'End'.
2. During this execution, the setTimeout callback is placed in the Macrotask Queue and the Promise.then callback is placed in the Microtask Queue.
3. After the call stack is empty, the event loop processes the entire Microtask Queue before moving to the Macrotask Queue.
4. The microtask ('Promise') is executed and logged.
5. The Microtask Queue is now empty, so the event loop processes the next task in the Macrotask Queue ('Timeout'), which is then logged.

1. Sync: 'F' is logged. Macrotask for 'A' is queued. Microtasks for 'B' and 'D' are queued.
2. End of Sync task: Event loop must empty the Microtask Queue.
3. Microtask 1: 'B' is logged. A new macrotask for 'C' is queued.
4. Microtask 2: 'D' is logged. A new microtask for 'E' is queued. The event loop must process this new microtask before moving on.
5. Microtask 3: 'E' is logged.
6. Microtask Queue is empty.
7. Event Loop starts a new tick: It picks the first Macrotask, which is 'A'. 'A' is logged.
8. Macrotask 'A' finishes. The event loop checks for microtasks (none) and starts the next tick.
9. Event Loop picks next Macrotask: It picks 'C'. 'C' is logged.

1. Synchronous Execution: 'D' is logged. setTimeout queues macrotask 'E'. async1 is called. 'A' is logged. async2 is called and 'C' is logged. The code continues synchronously. The Promise executor runs, logging 'F'. Its .then (for 'G') is queued as a microtask. Finally, 'H' is logged. So far: D, A, C, F, H.
2. Microtask Queue: After the main script, microtasks run. The await in async1 causes the rest of that function (logging 'B') to be queued as a microtask. The .then for 'G' is also a microtask. In modern engines, the .then is generally queued before the await continuation resumes. Thus, 'G' is logged, then 'B' is logged.
3. Macrotask Queue: After all microtasks are done, the event loop picks up the macrotask. 'E' is logged.
   Final order: D, A, C, F, H, G, B, E.

The function uses object destructuring with default values for its parameters.

• width: The settings object provides a width of 800, so this value overrides the default of 1024.
• height: The settings object does not have a height property, so the default value of 768 is used.
• theme: The settings object provides a theme of 'dark'. Even though there's no default value for theme in the function signature, a value is provided, so it is used.

This code demonstrates two different ES6 features: rest parameters and the spread syntax.

1. Rest Parameters: In the function signature (first, ...args), ...args is a rest parameter. It collects all remaining arguments into an array. So, first is 'a' and args becomes the array ['b', 'c', 'd'].
2. Spread Syntax: Inside the function, [...args, first] uses the spread syntax. ...args expands the ['b', 'c', 'd'] array into its individual elements within a new array literal. Then, the first variable, 'a', is added to the end. The final result is ['b', 'c', 'd', 'a'].

ES modules syntactically support importing the default export and named exports in a single statement.

• import calculateArea, ...: calculateArea is the name given to the imported default export (which is the area function).
• ... { PI as piValue }: This imports the named export PI and renames it locally to piValue.
  The code correctly calls calculateArea(10), which uses the exported PI to return 314. It also correctly logs piValue, which is the imported value of PI, 3.14.

This demonstrates that ES modules have 'live bindings'. When you import a variable, you are not getting a copy of its value; you are getting a live link to the variable in the original module. While you cannot reassign the imported variable directly in main.js (e.g., count = 5 would throw an error), when the increment function (which lives in counter.js) modifies the original count variable, the change is reflected in main.js. The first log shows the initial value 0, and the second log shows the updated value 1.

The Immediately Invoked Function Expression (IIFE) creates a single closure. The myModule variable holds the object returned by the IIFE. This object's methods (getVar and updateVar) maintain access to the privateVar within that closure. Since anotherRef is just another reference to the same object as myModule, calling anotherRef.updateVar('changed') modifies the privateVar inside the one-and-only closure. Therefore, myModule.getVar() returns the updated value.

1. Synchronous Code: console.log(1), the Promise constructor console.log(5), and console.log(8) run first. The call stack executes them in order.
2. Queueing: During synchronous execution, setTimeout queues a macrotask (logging 2, 3, 4), the Promise.then queues a microtask (logging 6), and queueMicrotask queues another microtask (logging 7).
3. Microtask Phase: After the call stack is empty, the microtask queue is processed entirely. then was queued first, so 6 is logged. Then queueMicrotask's callback runs, logging 7.
4. Macrotask Phase: The event loop picks up the next macrotask from the macrotask queue, which is the setTimeout callback.
5. Inside Macrotask: console.log(2) runs, then a new Promise.resolve().then() queues a microtask (logging 3). console.log(4) runs. Before the setTimeout callback finishes, the newly queued microtask (log 3) is processed. After the macrotask completes, any microtasks queued during its execution are run. Thus, 3 is logged after 2 and 4.

Final order: 1, 5, 8 (sync) -> 6, 7 (microtasks) -> 2, 4 (sync part of macrotask) -> 3 (microtask from macrotask).

The instanceof operator checks if the prototype property of a constructor appears anywhere in an object's prototype chain.

1. The prototype chain for b is: b -> B.prototype -> A.prototype -> Object.prototype -> null.
2. The statement C.prototype = A.prototype; makes the prototype property of constructor C point to the same object as A.prototype.
3. The check b instanceof C looks for C.prototype in b's prototype chain.
4. Since C.prototype is A.prototype, the check is effectively looking for A.prototype in b's prototype chain.
5. As we established in step 1, A.prototype is indeed in b's prototype chain. Therefore, the expression evaluates to true.

1. logger1 and logger2 are created from createAsyncLogger. Each has its own independent, closed-over log array.
2. logger1("A") is called. It pushes "A" to logger1's log array (['A']) and schedules a setTimeout to resolve its promise. No .then() is attached to this call, so its resolved value is not logged.
3. logger2("B").then(...) is called. It pushes "B" to logger2's log array (['B']) and schedules a setTimeout. Its .then() callback will log the value of logger2's log array.
4. logger1("C").then(...) is called. It pushes "C" to logger1's log array (['A', 'C']) and schedules a third setTimeout. Its .then() callback will log the value of logger1's log array.
5. All three setTimeout calls have a delay of 0, so their callbacks are added to the macrotask queue in the order they were scheduled.
6. The event loop picks up the first task: the callback for logger2. It resolves the promise with ['B'], and the .then() logs ["B"].
7. The event loop picks up the next task: the callback for logger1("C"). It resolves the promise with ['A', 'C'], and its .then() logs ["A", "C"].

1. The for...of loop starts iterating over the gen2 generator.
2. First iteration: yield 1 is executed. val is 1, result becomes [1].
3. Second iteration: The generator enters yield* gen1(). The first yield inside gen1 is yield 2. val becomes 2, result becomes [1, 2].
4. The condition if (val === 2) is now true.
5. iterator.return('finished') is called. This method immediately terminates the generator (both gen1 and gen2 because of yield*) and returns an object { value: 'finished', done: true }.
6. The for...of loop respects the iterator protocol and stops iterating when it receives an object with done: true.
7. The loop terminates, and no more values are pushed to the result array. The final value of result is [1, 2].

JavaScript's eval function has unique behavior regarding scope. When called directly as eval(...), it executes in the local scope of the caller. However, when it is called indirectly—for instance, by assigning it to another variable and calling it through that variable as indirectEval(...)—it executes in the global scope.
In this code, eval is assigned to indirectEval. The call indirectEval('console.log(x)') is an indirect call. Therefore, the code inside eval is executed within the global execution context, where x has the value 'global'. The local variable x with the value 'local' is ignored.

Wait, let me rethink the async/await timing. The execution of an async function is split into parts. The part before the first await runs synchronously. The part after the await is scheduled to run later, once the promise resolves. So the console.log('End') will definitely run after the promise from Promise.all settles. My first trace was correct. Let's re-verify. No, await pauses the function. The code after the await line runs when the promise settles. Let's re-trace. 1. main starts. 2. Start is logged. 3. Promise.all starts. main is paused. 4. After 100ms, fetcher('B') rejects. The Promise.all rejects. 5. The await throws an error. The catch block runs. 6. Caught: B is logged. 7. The try-catch is done. main continues. 8. End is logged. So the order is Start, Caught: B, End. Let's check my options. Option A is Start -> Caught: B -> End. What about Start -> End -> Caught: B? This would imply main continues before the await settles, which is wrong. OK, let's look closer at the provided options. Ah, the options might be testing a more subtle interaction. Let's consider the microtask timing. The continuation of main after the await is scheduled as a microtask. So the trace Start -> pause main -> B rejects after 100ms -> continuation of main is queued -> Caught: B is logged -> End is logged. The order seems to be Start, Caught: B, End. Let me re-read the question carefully. Maybe I misunderstood something. Ah, I see the potential trap. Let's assume a slightly different snippet:
async function main() { ... }; main(); console.log('Script End');
In this case, the output would be Start -> Script End -> Caught: B -> End. The question does not have Script End. It only asks for the output from the main call. Let's stick to the simple trace. But perhaps the options imply a misunderstanding from the question author. Let's consider Start -> End -> Caught: B. This is only possible if main is not async or if Promise.all doesn't block. This is incorrect. Therefore Start -> Caught: B -> End must be the right sequence. I'll stick with that logic. My own reasoning makes option B (Start -> End -> Caught: B) incorrect. But wait, I might have fallen into a common trap. await only pauses the async function, not the entire program. The main() call itself returns a Promise immediately. But there's no code outside main() in the snippet. So the entire program just waits. The trace Start -> (100ms pause) -> Caught: B -> End seems correct. Let me review the options. Why would option B be there? It's a common confusion where people think .then() or await continuations happen after the current "task" ends, which might include synchronous code after the async call. But here, everything is inside the async function. The control flow is sequential within the function, just paused by await. Option A is the most logical one. Let me re-verify my understanding. async function f() { console.log(1); await p; console.log(2); }. 1 is logged, f is paused. When p settles, log(2) is queued. Yes, so End must come after the try/catch. It seems Option A is the only logical choice. I will generate it as such. But let me reconsider the End placement. It's outside the try-catch. Yes. It will run after the try-catch block completes, either normally or via the catch path. So it is definitely last. It's between Start and Caught: B. Start is sync. await pauses. When promise rejects, catch block runs. Then End runs. A is correct. Why is B an option? What if the promise settlement and the catch block are scheduled for a future turn of the event loop, and somehow End runs before it? No, that's not how await works. I will stick to my initial analysis. Let me check a different resource. Yes, the body of an async function is split by await. Everything after await is conceptually wrapped in a .then(). So try { await ... } catch { ... } runs to completion before the line console.log('End'). Therefore the order Start, Caught: B, End is correct.

ES Modules create live, read-only bindings to exported variables.

1. console.log(count) logs the initial value, 0.
2. increment() is called. This function is in counter.js and modifies the count variable within its own module scope. Because the import is a live binding, this change is reflected in main.js.
3. console.log(count) now logs the updated value, 1.
4. The line count = 10; attempts to assign a new value to the imported binding count. This is not allowed. Imported bindings are read-only. Attempting to assign to them will result in a TypeError in strict mode (and module code is implicitly in strict mode).

1. Start is logged synchronously.
2. setTimeout is called. The browser/Node.js API schedules a timer to add the callback to the macrotask queue after ~20ms.
3. new Promise(...) is created. The executor function runs synchronously. The while loop blocks the main thread for 100ms. During these 100ms, nothing else can happen, including the timer firing.
4. After the 100ms blocking loop, resolve('Promise finished') is called. This queues a microtask for the .then() callback.
5. End is logged synchronously.
6. The synchronous script has finished. The event loop checks the microtask queue. It finds the .then() callback and executes it, logging Promise finished.
7. The microtask queue is now empty. The event loop checks the macrotask queue. The 20ms timer has long since expired during the 100ms block, so its callback is waiting. It gets executed, logging Timeout finished.
   Final Order: 'Start', 'End', 'Promise finished', 'Timeout finished'.

1. Sync: D is logged. setTimeout queues E as a macrotask.
2. async1() call: async1 starts executing synchronously. A is logged. async2() is called.
3. async2() call: C is logged. async2 returns an implicitly resolved promise.
4. await: The await pauses async1. The code after await (console.log('B')) is scheduled as a microtask to run when the promise from async2 resolves.
5. Sync continues: Execution continues in the main script. The Promise constructor runs, logging F. The .then callback (logging G) is scheduled as a microtask.
6. Sync ends: H is logged. The call stack is now empty.
7. Microtasks: The microtask queue is processed. The async1 continuation (log 'B') was queued first, followed by the promise's .then (log 'G'). So, B is logged, then G is logged.
8. Macrotasks: The microtask queue is empty. The event loop processes the macrotask queue. The setTimeout callback runs, logging E.
   Final Order: D, A, C, F, H, B, G, E.

Let's break down the destructuring:

1. user: { name: userName, ...restOfUser }: This destructures the user object. It renames name to userName. The ...restOfUser syntax collects all remaining properties of the user object into restOfUser. So, restOfUser will be { address: { city: 'NY', country: 'USA' } }.
2. posts: [firstPost, ]: This destructures the posts array. firstPost gets the first element, which is the object { title: 'Post 1', tags: ['a'] }. The trailing comma indicates we are ignoring the rest of the elements.
3. id: userID = 10: This renames id to userID. The default value = 10 is only used if data.id is undefined. Since data.id is 1, userID will be 1.

Assembling the result object gives the correct JSON output.

Promise.race(iterable) returns a promise that settles as soon as one of the promises in the iterable settles. A crucial edge case is how it handles non-promise values. If a non-promise value (like the string 'Instant Value') is present in the iterable, it is treated as an already-resolved promise. Therefore, Promise.race resolves immediately with this value, winning the race before p1 or p2 have a chance to settle. The await receives the resolved value 'Instant Value', which is then logged. The catch block is never reached.

1. myObj.regularFunc(): regularFunc is a standard function called on myObj, so its this is myObj. The arrowFunc inside it inherits this lexical this. Therefore, arrowFunc logs this.name which is myObj.name, outputting MyObj.
2. myObj.arrowHost().run(): arrowHost is a regular function called on myObj, so its this is myObj. The arrowFuncInArrow inside it lexically captures this this context. Even though run is called on a new object, the this inside arrowFuncInArrow was fixed when it was defined. It will still refer to myObj, logging MyObj.
3. myObj.topLevelArrow(): topLevelArrow is an arrow function defined directly on the object literal. Arrow functions do not have their own this; they inherit it from their enclosing lexical scope. In this case, the enclosing scope is the global scope where the myObj object is defined. In a browser, the global this is window. Therefore, it logs this.name from the global scope, which is Window.

The memory leak is caused by a long-lived closure unnecessarily keeping a reference to a large object.

• Option A: The event listener's callback is a closure that references both data and id. Because the entire data array is referenced, the JavaScript engine must keep it in memory as long as the event listener exists, even if the element is removed from the DOM but the listener is not explicitly removed. This prevents the large array from being garbage collected.
• Option B and C: In these cases, the closure only captures the specificValue (or val) variable, which holds a single primitive value from the array. The closure does not maintain a reference to the large data array itself. Once the setupElement function finishes, if there are no other references to data, it can be garbage collected.
• Option D: This function uses this, which refers to the element itself, and does not create a closure over the data array.

1. Initially, myPet's prototype chain is myPet -> dog -> animal -> Object.prototype. At this point, myPet.bark() would work.
2. The line Object.setPrototypeOf(myPet, cat); completely changes the immediate prototype of myPet. The new chain for myPet becomes myPet -> cat.
3. The line Object.setPrototypeOf(cat, animal); further extends this new chain. The final prototype chain for myPet is myPet -> cat -> animal -> Object.prototype.
4. Crucially, the dog object is no longer in myPet's prototype chain.
5. When the code myPet.bark is evaluated, JavaScript searches the chain (myPet, cat, animal, Object.prototype) for a property named bark. It is not found.
6. Therefore, myPet.bark evaluates to undefined.
7. The ternary expression undefined ? ... : 'No bark' evaluates to the second part, 'No bark'.

This question tests the singleton nature of ES modules and the timing of dynamic imports.

1. Sync Execution: The main.js script runs. Main script start is logged.
2. The first import('./widget.js') is called. It starts loading the module asynchronously and queues its .then() callback as a microtask.
3. loadWidget() is called. Inside loadWidget is logged synchronously.
4. Inside loadWidget, the second import('./widget.js') is encountered via await. The function pauses.
5. Sync Continues: Main script end is logged.
6. Microtask/Async Phase: The call stack is now empty. The module system finishes loading widget.js. An ES module's body is executed only once, the first time it is imported.
7. Widget module executed is logged.
8. The promises from both import() calls are now ready to be resolved. Microtasks are processed in the order they are queued.
9. The .then() from the first import runs, logging First import resolved.
10. The await in loadWidget receives the resolved module. The function resumes, calls the default export, and logs I am a widget.

1. The code is in strict mode ('use strict').
2. The try block begins. The line proxy.value = 'hello'; triggers the set trap in the proxy handler.
3. Inside the set trap, the condition prop === 'value' && typeof value !== 'number' is true ('hello' is not a number).
4. The trap returns false.
5. In strict mode, when a set trap returns false, it signifies that the assignment failed, and a TypeError is automatically thrown by the JavaScript engine.
6. This TypeError is caught by the catch block.
7. The catch block assigns the name property of the error object ('TypeError') to the output variable.
8. The rest of the try block, output = proxy._id;, is never executed. The final value of output is 'TypeError'.

1. Sync Execution: The Promise executor runs synchronously, so A is logged immediately. The promise is resolved with 1. The subsequent reject call is ignored because a promise can only be settled once. Then, F is logged.
2. Microtask 1 (.then): The first .then is queued as a microtask. It runs, logging B. Then it throws a new error. This immediately rejects the promise it returns. The return statement is unreachable.
3. Promise Rejection: Because the previous promise was rejected, the next .then (which would log D) is skipped entirely.
4. Microtask 2 (.catch): The .catch handler is executed to handle the rejection. It logs the error's message, C.
5. Recovery: The .catch handler returns a value ('E'). This is important: returning a value from .catch resolves the promise chain, allowing subsequent .then handlers to execute. The promise returned by .catch resolves with the value 'E'.
6. Microtask 3 (.then): The final .then receives the resolved value from the .catch block and logs it, which is E.

Combining the synchronous logs and the microtask logs gives the final order: A, F, B, C, E.

The compose function creates a new function by chaining two functions together. The execution flows from right to left (inside-out).

1. The inner compose(multiplyBy2, add5) is evaluated first. It creates a function that takes an argument x, applies add5(x), and then applies multiplyBy2 to that result. Let's call this intermediate function h(x).
2. The outer compose(subtract10, h) is evaluated. It creates the final composedFunc. This function will take an argument x, apply h(x), and then apply subtract10 to that result.
3. The call composedFunc(10) triggers the chain:
   • add5(10) results in 15.
   • multiplyBy2(15) results in 30.
   • subtract10(30) results in 20.
     Each composed function is a closure, capturing the functions f and g that it needs to execute later.

JavaScript's concurrency model is based on a single-threaded event loop. When setTimeout(callback, delay) is called, a timer is started in the environment's API (e.g., browser). After delay milliseconds, the API places the callback into the macrotask queue.
However, the event loop will only check the macrotask queue when the call stack is empty. In this example, the long for loop is a synchronous task that runs on the call stack. It will run to completion, blocking the main thread for much longer than 10ms. Only after the loop finishes and the script execution is complete will the call stack be empty. At that point, the event loop can finally pick up the setTimeout callback from the macrotask queue and execute it. This means the specified delay is a minimum delay, not a guaranteed one.

1. obj1 = new F(): The new keyword creates a new object (obj1) and sets its internal [[Prototype]] link (commonly accessible as __proto__) to the constructor's prototype property. Therefore, obj1.__proto__ === F.prototype is true.
2. obj2 = Object.create(F.prototype): Object.create() creates a new object (obj2) with its [[Prototype]] link set to the object passed as the first argument. So, obj2.__proto__ === F.prototype is also true.
3. The constructor property: The .constructor property is not on the instance itself but is inherited from the prototype. F.prototype has a default .constructor property that points back to F. Thus, obj1.constructor resolves to F.
   A) obj1.__proto__ === F.prototype (true). obj2.constructor refers to Object (false, it's F).
   B) obj1.prototype (undefined). Incorrect.
   C) obj1.__proto__ === F.__proto__ (false). Incorrect.
   D) obj2 has a direct constructor property (false). Incorrect.
   There seems to be an issue with the provided options versus the expected JavaScript behavior. Let me craft a better question and set of answers around this topic. Let's fix option A to be fully correct.

New Correct Option/Explanation:
obj1.__proto__ is strictly equal to F.prototype, and obj2.constructor inherited from its prototype is F.

Let's assume the original intent of the question was to highlight that obj2 has no own constructor property. The lookup for .constructor on obj2 will traverse the prototype chain to F.prototype, where it finds the property pointing to F. The original option A is flawed. I will generate a correct version.

Let's change the option slightly to make it correct and hard. Let's say: ... and obj2.hasOwnProperty('constructor') is false.
obj1.__proto__ === F.prototype (true). obj2.hasOwnProperty('constructor') is false (true). This is a good hard question.

Let me rewrite the answer based on this new premise.