Work That Finishes Later
Keep a school screen useful while a report is pending
A student requests a report that is stored on a server. Its arrival depends on a network response, so the screen needs to represent waiting rather than pretending the report is immediately available.
Asynchronous programming lets an operation report its result later. The program arranges what to do on completion and can continue other work while the result is pending. Later completion can mean success or failure.
Represent waiting
Distinguish pending, successful and failed states.
Trace later work
Predict synchronous statements before promise handlers.
Recognize limits
Explain why asynchrony does not guarantee parallel computation.
Waiting is a state, not a finished report
Request
Arrange how to handle the eventual result.
PendingOther work
Display a useful waiting state.
Loading reportCompletion
Use the report or explain the failure.
Success or failure
Arrange a later response rather than using a missing value
JavaScript promises represent eventual success or failure. A then handler receives a fulfilled value; a catch handler can handle rejection. These handlers do not run during the synchronous statements that attach them.
The example uses Promise.resolve with a local string, so there is no server or network delay. The promise is already fulfilled, but its handler still runs later, after the current synchronous sequence. This isolates scheduling from unpredictable networking.
Before starting, review callbacks as function values. These examples use JavaScript; other languages can use different syntax and rules.
See what runs before the report handler
The first log requests the report. Attaching then schedules its handler; it does not display the result immediately. The next synchronous log shows Loading report.
After the synchronous code finishes, the handler displays Maya: 75. This order is guaranteed for this single fulfilled-promise example, rather than measured from a network request.
JavaScript · local teaching example
console.log("Request report");
const report = Promise.resolve("Maya: 75");
report.then(text => console.log(text));
console.log("Loading report");Expected output
Request report
Loading report
Maya: 75Later completion can also fail
This local promise is deliberately rejected. The catch handler displays the reason after the current Waiting log. A real interface should give users an appropriate failure state and a supported recovery action.
JavaScript · local teaching example
Promise.reject(new Error("Report unavailable"))
.catch(error => console.log(error.message));
console.log("Waiting");Expected output
Waiting
Report unavailableApply the rule to a small change
Attach a handler to a fulfilled promise containing Ready, then print Still working synchronously. Predict the order.
Worked answer
Still working prints first because attaching then does not call the handler inline. Ready prints when the promise handler runs afterward.
JavaScript · local teaching example
Promise.resolve("Ready").then(value => console.log(value));
console.log("Still working");Expected output
Still working
ReadyRecognize mistakes and limits
Asynchronous does not mean parallel. A long JavaScript loop still occupies the current execution thread and can delay the interface and scheduled handlers. Moving CPU-heavy work may require a worker or a different design.
Never treat a pending value as the completed report. Keep loading, success and failure states distinct, and prevent actions that require data until that data exists.
Real requests have variable timing. The checked ordering here concerns the synchronous sequence and promise handlers; it does not promise a network response time or guarantee that multiple requests finish in the order started.
For the language or tool rules used here, see JavaScript promise chaining and timing.
Check the core idea
JavaScript · code for this question
console.log("Request report");
const report = Promise.resolve("Maya: 75");
report.then(text => console.log(text));
console.log("Loading report");Apply the idea to a new situation
Design for an eventual result and its possible failure
Asynchronous work reports completion later. Represent waiting honestly, handle both outcomes and distinguish scheduling from parallel computation.
Connect this idea with exact execution order and network requests, timers and events.
Reaching the recap and completing the quizzes are separate milestones.