When a learner can reproduce a familiar example but a small variation causes confusion, the problem is usually an incomplete model rather than a lack of effort. The fastest useful response is to expose the hidden state and test one boundary at a time.

JavaScript Array.prototype.toSorted() returns a new, shallowly copied array in sorted order while leaving the receiver unchanged. That simple promise has precise edges: the default comparison orders string forms by UTF-16 code units, a comparator communicates only negative, zero or positive, the sort is stable, undefined values move after defined values without entering the comparator, sparse holes are read through as undefined and become actual elements, and nested objects remain shared references. Mastery means protecting the old sequence without inventing deep immutability and writing a comparator whose ordering is pure, consistent and testable. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.

The aim is independent reasoning. A learner should be able to predict behaviour, locate the earliest wrong assumption, use a safe diagnostic procedure and defend a design choice in a new project.

Punggol families can use the guide in short sessions around homework, CCAs and rest. The activities are proposed learning exercises, not claims about a physical branch, timetable, class size, fee, school relationship or guaranteed result.

Use disposable data and repositories, preserve backups, and check version-sensitive details against the official source. Current documentation settles a technical contract; observation and explanation turn that contract into usable knowledge.

toSorted creates a new ordinary Array and does not reorder the receiver. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is checking only the values and missing the identity and mutation guarantees. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for toSorted returns a new array, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the toSorted returns a new array chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on checking only the values and missing the identity and mutation guarantees. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const a=[3,1,2]; const b=a.toSorted((x,y)=>x-y); console.log(a,b,a===b);

Four purposeful transfer cases

Case 1: homework priorities. Predict the rule using tasks are ranked while the original capture order remains evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading list. Contrast the rule using titles use a locale-aware collator without mutating the saved list. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science results. Stress-test the rule using numeric readings are sorted while equal values keep arrival order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA roster. Explain the rule using members are sorted by group and then stable signup order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers checking only the values and missing the identity and mutation guarantees.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for toSorted returns a new array, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from toSorted returns a new array?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing checking only the values and missing the identity and mutation guarantees be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny transport times with undefined observations move to the end and remain explicit. Include one ordinary case, one boundary and one deliberate failure caused by checking only the values and missing the identity and mutation guarantees. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For toSorted returns a new array, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Without compareFn, defined elements are converted to strings and ordered by UTF-16 code units. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is expecting ordinary numeric order from an array of numbers. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for The default comparison uses string forms, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the The default comparison uses string forms chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on expecting ordinary numeric order from an array of numbers. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

console.log([2,10,1].toSorted());

Four purposeful transfer cases

Case 1: science results. Contrast the rule using numeric readings are sorted while equal values keep arrival order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA roster. Stress-test the rule using members are sorted by group and then stable signup order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: budget entries. Explain the rule using amounts are ranked without cloning nested category objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: transport times. Transfer the rule using undefined observations move to the end and remain explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers expecting ordinary numeric order from an array of numbers.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for The default comparison uses string forms, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from The default comparison uses string forms?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing expecting ordinary numeric order from an array of numbers be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with numbers, strings, holes, undefined, NaN and shared objects expose boundaries. Include one ordinary case, one boundary and one deliberate failure caused by expecting ordinary numeric order from an array of numbers. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The default comparison uses string forms, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

A comparator returning a-b places smaller finite numbers before larger ones. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is returning a boolean and relying on accidental coercion. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for A numeric comparator states ascending order, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the A numeric comparator states ascending order chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on returning a boolean and relying on accidental coercion. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

console.log([20,3,11].toSorted((a,b)=>a-b));

Four purposeful transfer cases

Case 1: budget entries. Stress-test the rule using amounts are ranked without cloning nested category objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: transport times. Explain the rule using undefined observations move to the end and remain explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Transfer the rule using numbers, strings, holes, undefined, NaN and shared objects expose boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Predict the rule using toSorted is compared with sort, spread-plus-sort and typed-array sorting. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers returning a boolean and relying on accidental coercion.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for A numeric comparator states ascending order, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from A numeric comparator states ascending order?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing returning a boolean and relying on accidental coercion be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design decision with toSorted is compared with sort, spread-plus-sort and typed-array sorting. Include one ordinary case, one boundary and one deliberate failure caused by returning a boolean and relying on accidental coercion. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For A numeric comparator states ascending order, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The algorithm interprets a negative result as a before b, positive as after, and zero or NaN as tied. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is trying to return the desired position index from the comparator. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Only comparator sign matters, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Only comparator sign matters chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on trying to return the desired position index from the comparator. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const byLength=['pear','fig','plum'].toSorted((a,b)=>a.length-b.length); console.log(byLength);

Four purposeful transfer cases

Case 1: test laboratory. Explain the rule using numbers, strings, holes, undefined, NaN and shared objects expose boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Transfer the rule using toSorted is compared with sort, spread-plus-sort and typed-array sorting. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework priorities. Predict the rule using tasks are ranked while the original capture order remains evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading list. Contrast the rule using titles use a locale-aware collator without mutating the saved list. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers trying to return the desired position index from the comparator.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Only comparator sign matters, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from Only comparator sign matters?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing trying to return the desired position index from the comparator be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework priorities with tasks are ranked while the original capture order remains evidence. Include one ordinary case, one boundary and one deliberate failure caused by trying to return the desired position index from the comparator. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Only comparator sign matters, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Elements that compare as equal retain their original relative order. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is adding an unnecessary second key and destroying meaningful arrival order. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for The sort is stable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the The sort is stable chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on adding an unnecessary second key and destroying meaningful arrival order. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const rows=[{g:2,id:'A'},{g:1,id:'B'},{g:2,id:'C'}]; console.log(rows.toSorted((a,b)=>a.g-b.g).map(x=>x.id));

Four purposeful transfer cases

Case 1: homework priorities. Transfer the rule using tasks are ranked while the original capture order remains evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading list. Predict the rule using titles use a locale-aware collator without mutating the saved list. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science results. Contrast the rule using numeric readings are sorted while equal values keep arrival order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA roster. Stress-test the rule using members are sorted by group and then stable signup order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers adding an unnecessary second key and destroying meaningful arrival order.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for The sort is stable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from The sort is stable?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing adding an unnecessary second key and destroying meaningful arrival order be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny reading list with titles use a locale-aware collator without mutating the saved list. Include one ordinary case, one boundary and one deliberate failure caused by adding an unnecessary second key and destroying meaningful arrival order. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The sort is stable, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

A comparator should return the same relation for the same pair and avoid mutating compared values or outside state. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using random numbers, clock time or side effects as ordering evidence. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Comparator purity makes results explainable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Comparator purity makes results explainable chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using random numbers, clock time or side effects as ordering evidence. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const ranked=items.toSorted((a,b)=>a.score-b.score);

Four purposeful transfer cases

Case 1: science results. Predict the rule using numeric readings are sorted while equal values keep arrival order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA roster. Contrast the rule using members are sorted by group and then stable signup order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: budget entries. Stress-test the rule using amounts are ranked without cloning nested category objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: transport times. Explain the rule using undefined observations move to the end and remain explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using random numbers, clock time or side effects as ordering evidence.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Comparator purity makes results explainable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from Comparator purity makes results explainable?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using random numbers, clock time or side effects as ordering evidence be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science results with numeric readings are sorted while equal values keep arrival order. Include one ordinary case, one boundary and one deliberate failure caused by using random numbers, clock time or side effects as ordering evidence. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Comparator purity makes results explainable, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Undefined elements sort after all other elements and compareFn is not called for those undefined values. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is writing comparator branches for undefined and assuming they execute. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Undefined values move after defined values, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Undefined values move after defined values chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on writing comparator branches for undefined and assuming they execute. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const seen=[]; const r=[3,undefined,1].toSorted((a,b)=>{seen.push([a,b]);return a-b}); console.log(r,seen);

Four purposeful transfer cases

Case 1: budget entries. Contrast the rule using amounts are ranked without cloning nested category objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: transport times. Stress-test the rule using undefined observations move to the end and remain explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Explain the rule using numbers, strings, holes, undefined, NaN and shared objects expose boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Transfer the rule using toSorted is compared with sort, spread-plus-sort and typed-array sorting. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers writing comparator branches for undefined and assuming they execute.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Undefined values move after defined values, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from Undefined values move after defined values?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing writing comparator branches for undefined and assuming they execute be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA roster with members are sorted by group and then stable signup order. Include one ordinary case, one boundary and one deliberate failure caused by writing comparator branches for undefined and assuming they execute. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Undefined values move after defined values, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

toSorted reads through holes, treats them as undefined and creates a dense result with those undefined values at the end. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is expecting holes to remain absent properties as they can after sort. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Sparse holes are read as undefined, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Sparse holes are read as undefined chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on expecting holes to remain absent properties as they can after sort. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const a=[]; a[2]='x'; const b=a.toSorted(); console.log(b,0 in b,1 in b,2 in b);

Four purposeful transfer cases

Case 1: test laboratory. Stress-test the rule using numbers, strings, holes, undefined, NaN and shared objects expose boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Explain the rule using toSorted is compared with sort, spread-plus-sort and typed-array sorting. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework priorities. Transfer the rule using tasks are ranked while the original capture order remains evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading list. Predict the rule using titles use a locale-aware collator without mutating the saved list. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers expecting holes to remain absent properties as they can after sort.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Sparse holes are read as undefined, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from Sparse holes are read as undefined?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing expecting holes to remain absent properties as they can after sort be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny budget entries with amounts are ranked without cloning nested category objects. Include one ordinary case, one boundary and one deliberate failure caused by expecting holes to remain absent properties as they can after sort. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Sparse holes are read as undefined, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The outer array is new, but object elements remain the same references. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is calling toSorted a deep immutable update and then mutating a shared object. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for The copy is shallow, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the The copy is shallow chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling toSorted a deep immutable update and then mutating a shared object. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const x={n:2},y={n:1}; const r=[x,y].toSorted((a,b)=>a.n-b.n); r[1].n=9; console.log(x.n);

Four purposeful transfer cases

Case 1: homework priorities. Explain the rule using tasks are ranked while the original capture order remains evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading list. Transfer the rule using titles use a locale-aware collator without mutating the saved list. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science results. Predict the rule using numeric readings are sorted while equal values keep arrival order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA roster. Contrast the rule using members are sorted by group and then stable signup order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers calling toSorted a deep immutable update and then mutating a shared object.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for The copy is shallow, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from The copy is shallow?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling toSorted a deep immutable update and then mutating a shared object be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny transport times with undefined observations move to the end and remain explicit. Include one ordinary case, one boundary and one deliberate failure caused by calling toSorted a deep immutable update and then mutating a shared object. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The copy is shallow, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Object arrays need an explicit key rule because default string forms often do not represent the domain order. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is sorting objects without a comparator and trusting [object Object] text. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for The comparator can order object properties, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the The comparator can order object properties chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on sorting objects without a comparator and trusting [object Object] text. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const r=[{name:'B',score:4},{name:'A',score:7}].toSorted((a,b)=>b.score-a.score); console.log(r.map(x=>x.name));

Four purposeful transfer cases

Case 1: science results. Transfer the rule using numeric readings are sorted while equal values keep arrival order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA roster. Predict the rule using members are sorted by group and then stable signup order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: budget entries. Contrast the rule using amounts are ranked without cloning nested category objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: transport times. Stress-test the rule using undefined observations move to the end and remain explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers sorting objects without a comparator and trusting [object Object] text.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for The comparator can order object properties, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from The comparator can order object properties?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing sorting objects without a comparator and trusting [object Object] text be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with numbers, strings, holes, undefined, NaN and shared objects expose boundaries. Include one ordinary case, one boundary and one deliberate failure caused by sorting objects without a comparator and trusting [object Object] text. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The comparator can order object properties, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

A multi-key comparator should return the first non-zero comparison and then a deliberate secondary rule. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using logical OR with comparison values without understanding the zero fall-through. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Multi-key comparators must handle ties, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Multi-key comparators must handle ties chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using logical OR with comparison values without understanding the zero fall-through. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const r=rows.toSorted((a,b)=>(a.group-b.group)||a.name.localeCompare(b.name));

Four purposeful transfer cases

Case 1: budget entries. Predict the rule using amounts are ranked without cloning nested category objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: transport times. Contrast the rule using undefined observations move to the end and remain explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Stress-test the rule using numbers, strings, holes, undefined, NaN and shared objects expose boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Explain the rule using toSorted is compared with sort, spread-plus-sort and typed-array sorting. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using logical OR with comparison values without understanding the zero fall-through.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Multi-key comparators must handle ties, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from Multi-key comparators must handle ties?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using logical OR with comparison values without understanding the zero fall-through be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design decision with toSorted is compared with sort, spread-plus-sort and typed-array sorting. Include one ordinary case, one boundary and one deliberate failure caused by using logical OR with comparison values without understanding the zero fall-through. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Multi-key comparators must handle ties, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Intl.Collator.compare can provide locale- and option-aware text ordering more explicitly than default UTF-16 order. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is claiming one human alphabetic order works for every locale and numeric string policy. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Intl.Collator supplies reusable text comparison, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Intl.Collator supplies reusable text comparison chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on claiming one human alphabetic order works for every locale and numeric string policy. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const collator=new Intl.Collator('en-SG',{numeric:true,sensitivity:'base'}); const r=['item 10','Item 2'].toSorted(collator.compare);

Four purposeful transfer cases

Case 1: test laboratory. Contrast the rule using numbers, strings, holes, undefined, NaN and shared objects expose boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Stress-test the rule using toSorted is compared with sort, spread-plus-sort and typed-array sorting. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework priorities. Explain the rule using tasks are ranked while the original capture order remains evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading list. Transfer the rule using titles use a locale-aware collator without mutating the saved list. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers claiming one human alphabetic order works for every locale and numeric string policy.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Intl.Collator supplies reusable text comparison, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from Intl.Collator supplies reusable text comparison?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing claiming one human alphabetic order works for every locale and numeric string policy be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework priorities with tasks are ranked while the original capture order remains evidence. Include one ordinary case, one boundary and one deliberate failure caused by claiming one human alphabetic order works for every locale and numeric string policy. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Intl.Collator supplies reusable text comparison, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

If compareFn produces NaN, the abstract comparison result is treated as positive zero, so the pair is tied. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is letting missing numeric data become NaN and assuming it always moves last. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for NaN comparator results act like equality, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the NaN comparator results act like equality chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on letting missing numeric data become NaN and assuming it always moves last. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const r=[{v:2},{},{v:1}].toSorted((a,b)=>a.v-b.v);

Four purposeful transfer cases

Case 1: homework priorities. Stress-test the rule using tasks are ranked while the original capture order remains evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading list. Explain the rule using titles use a locale-aware collator without mutating the saved list. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science results. Transfer the rule using numeric readings are sorted while equal values keep arrival order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA roster. Predict the rule using members are sorted by group and then stable signup order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers letting missing numeric data become NaN and assuming it always moves last.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for NaN comparator results act like equality, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from NaN comparator results act like equality?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing letting missing numeric data become NaN and assuming it always moves last be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny reading list with titles use a locale-aware collator without mutating the saved list. Include one ordinary case, one boundary and one deliberate failure caused by letting missing numeric data become NaN and assuming it always moves last. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For NaN comparator results act like equality, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The method uses length and indexed properties, so it can be called on suitable array-like objects and returns an Array. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is requiring the receiver to inherit from Array. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for toSorted is generic over array-like receivers, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the toSorted is generic over array-like receivers chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on requiring the receiver to inherit from Array. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const obj={0:'b',1:'a',length:2}; const r=Array.prototype.toSorted.call(obj); console.log(r,Array.isArray(r));

Four purposeful transfer cases

Case 1: science results. Explain the rule using numeric readings are sorted while equal values keep arrival order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA roster. Transfer the rule using members are sorted by group and then stable signup order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: budget entries. Predict the rule using amounts are ranked without cloning nested category objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: transport times. Contrast the rule using undefined observations move to the end and remain explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers requiring the receiver to inherit from Array.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for toSorted is generic over array-like receivers, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from toSorted is generic over array-like receivers?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing requiring the receiver to inherit from Array be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science results with numeric readings are sorted while equal values keep arrival order. Include one ordinary case, one boundary and one deliberate failure caused by requiring the receiver to inherit from Array. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For toSorted is generic over array-like receivers, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Reading indexed properties can invoke getters, so a non-mutating result does not mean the operation has no observable effects. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is placing stateful getters in an array-like object and expecting pure input reads. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Getters can make reads observable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Getters can make reads observable chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on placing stateful getters in an array-like object and expecting pure input reads. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const obj={length:1,get 0(){console.log('read');return 'x'}}; Array.prototype.toSorted.call(obj);

Four purposeful transfer cases

Case 1: budget entries. Transfer the rule using amounts are ranked without cloning nested category objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: transport times. Predict the rule using undefined observations move to the end and remain explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Contrast the rule using numbers, strings, holes, undefined, NaN and shared objects expose boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Stress-test the rule using toSorted is compared with sort, spread-plus-sort and typed-array sorting. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers placing stateful getters in an array-like object and expecting pure input reads.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Getters can make reads observable, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from Getters can make reads observable?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing placing stateful getters in an array-like object and expecting pure input reads be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA roster with members are sorted by group and then stable signup order. Include one ordinary case, one boundary and one deliberate failure caused by placing stateful getters in an array-like object and expecting pure input reads. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Getters can make reads observable, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Typed arrays provide a separate toSorted operation that returns the same typed-array kind and uses numeric ordering by default. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is borrowing every Array rule, including default string comparison, for typed arrays. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for TypedArray toSorted has its own method, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the TypedArray toSorted has its own method chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on borrowing every Array rule, including default string comparison, for typed arrays. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const a=new Uint8Array([10,2,1]); const b=a.toSorted(); console.log([...a],[...b],b instanceof Uint8Array);

Four purposeful transfer cases

Case 1: test laboratory. Predict the rule using numbers, strings, holes, undefined, NaN and shared objects expose boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Contrast the rule using toSorted is compared with sort, spread-plus-sort and typed-array sorting. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework priorities. Stress-test the rule using tasks are ranked while the original capture order remains evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading list. Explain the rule using titles use a locale-aware collator without mutating the saved list. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers borrowing every Array rule, including default string comparison, for typed arrays.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for TypedArray toSorted has its own method, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from TypedArray toSorted has its own method?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing borrowing every Array rule, including default string comparison, for typed arrays be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny budget entries with amounts are ranked without cloning nested category objects. Include one ordinary case, one boundary and one deliberate failure caused by borrowing every Array rule, including default string comparison, for typed arrays. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For TypedArray toSorted has its own method, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Preserving the receiver makes before-and-after comparison easier, but either array can still be mutated later unless the application imposes another policy. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is equating a copying method with Object.freeze or persistent data structures. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Non-mutation supports snapshots, not frozen data, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Non-mutation supports snapshots, not frozen data chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on equating a copying method with Object.freeze or persistent data structures. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const before=[3,1]; const after=before.toSorted(); after.push(4); console.log(before,after);

Four purposeful transfer cases

Case 1: homework priorities. Contrast the rule using tasks are ranked while the original capture order remains evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading list. Stress-test the rule using titles use a locale-aware collator without mutating the saved list. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science results. Explain the rule using numeric readings are sorted while equal values keep arrival order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA roster. Transfer the rule using members are sorted by group and then stable signup order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers equating a copying method with Object.freeze or persistent data structures.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Non-mutation supports snapshots, not frozen data, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from Non-mutation supports snapshots, not frozen data?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing equating a copying method with Object.freeze or persistent data structures be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny transport times with undefined observations move to the end and remain explicit. Include one ordinary case, one boundary and one deliberate failure caused by equating a copying method with Object.freeze or persistent data structures. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Non-mutation supports snapshots, not frozen data, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

[…array].sort(compareFn) can express a similar shallow-copy result, while toSorted states the copying intent directly and has defined hole treatment. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is replacing code mechanically without checking sparse arrays and supported runtimes. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Compare to spread followed by sort, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Compare to spread followed by sort chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on replacing code mechanically without checking sparse arrays and supported runtimes. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const oldWay=[...a].sort(compareFn); const direct=a.toSorted(compareFn);

Four purposeful transfer cases

Case 1: science results. Stress-test the rule using numeric readings are sorted while equal values keep arrival order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA roster. Explain the rule using members are sorted by group and then stable signup order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: budget entries. Transfer the rule using amounts are ranked without cloning nested category objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: transport times. Predict the rule using undefined observations move to the end and remain explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers replacing code mechanically without checking sparse arrays and supported runtimes.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Compare to spread followed by sort, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from Compare to spread followed by sort?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing replacing code mechanically without checking sparse arrays and supported runtimes be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with numbers, strings, holes, undefined, NaN and shared objects expose boundaries. Include one ordinary case, one boundary and one deliberate failure caused by replacing code mechanically without checking sparse arrays and supported runtimes. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Compare to spread followed by sort, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

A runtime can support Array and sort without implementing toSorted, so test the exact method where compatibility matters. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is inferring support from modern syntax or a browser name alone. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Feature detection protects older runtimes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Feature detection protects older runtimes chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on inferring support from modern syntax or a browser name alone. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

if(typeof Array.prototype.toSorted==='function'){ console.log('supported') }

Four purposeful transfer cases

Case 1: budget entries. Explain the rule using amounts are ranked without cloning nested category objects. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: transport times. Transfer the rule using undefined observations move to the end and remain explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Predict the rule using numbers, strings, holes, undefined, NaN and shared objects expose boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Contrast the rule using toSorted is compared with sort, spread-plus-sort and typed-array sorting. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers inferring support from modern syntax or a browser name alone.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Feature detection protects older runtimes, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from Feature detection protects older runtimes?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing inferring support from modern syntax or a browser name alone be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design decision with toSorted is compared with sort, spread-plus-sort and typed-array sorting. Include one ordinary case, one boundary and one deliberate failure caused by inferring support from modern syntax or a browser name alone. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Feature detection protects older runtimes, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Use toSorted for a new ordered view while preserving the source sequence; use sort when intentional in-place mutation is the contract. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is copying by habit when memory cost matters or mutating by habit when callers share the array. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Choose toSorted when the old order must remain evidence, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Choose toSorted when the old order must remain evidence chapter on JavaScript Array.prototype.toSorted(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on copying by habit when memory cost matters or mutating by habit when callers share the array. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const ranked=submissions.toSorted((a,b)=>b.score-a.score);

Four purposeful transfer cases

Case 1: test laboratory. Transfer the rule using numbers, strings, holes, undefined, NaN and shared objects expose boundaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Predict the rule using toSorted is compared with sort, spread-plus-sort and typed-array sorting. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework priorities. Contrast the rule using tasks are ranked while the original capture order remains evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading list. Stress-test the rule using titles use a locale-aware collator without mutating the saved list. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers copying by habit when memory cost matters or mutating by habit when callers share the array.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Choose toSorted when the old order must remain evidence, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Array.prototype.toSorted() syntax. For this chapter, useful prompts are: “What did you expect from Choose toSorted when the old order must remain evidence?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing copying by habit when memory cost matters or mutating by habit when callers share the array be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework priorities with tasks are ranked while the original capture order remains evidence. Include one ordinary case, one boundary and one deliberate failure caused by copying by habit when memory cost matters or mutating by habit when callers share the array. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Choose toSorted when the old order must remain evidence, separate the documented JavaScript Array.prototype.toSorted() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.

Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.

Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.

1. homework priorities: model, boundary and recovery

Create a small homework priorities using tasks are ranked while the original capture order remains evidence. Combine “toSorted returns a new array” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

2. reading list: model, boundary and recovery

Create a small reading list using titles use a locale-aware collator without mutating the saved list. Combine “Only comparator sign matters” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

3. science results: model, boundary and recovery

Create a small science results using numeric readings are sorted while equal values keep arrival order. Combine “Undefined values move after defined values” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

4. CCA roster: model, boundary and recovery

Create a small CCA roster using members are sorted by group and then stable signup order. Combine “The comparator can order object properties” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

5. budget entries: model, boundary and recovery

Create a small budget entries using amounts are ranked without cloning nested category objects. Combine “NaN comparator results act like equality” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

6. transport times: model, boundary and recovery

Create a small transport times using undefined observations move to the end and remain explicit. Combine “TypedArray toSorted has its own method” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

7. test laboratory: model, boundary and recovery

Create a small test laboratory using numbers, strings, holes, undefined, NaN and shared objects expose boundaries. Combine “Feature detection protects older runtimes” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

8. design decision: model, boundary and recovery

Create a small design decision using toSorted is compared with sort, spread-plus-sort and typed-array sorting. Combine “The default comparison uses string forms” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

Frequently asked questions

How long should a practice session be?

Use one complete prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be enough.

Should every option or function be memorised?

No. Memorise the governing distinctions and practise retrieving the official reference. Understanding means predicting and explaining, not reciting a parameter list.

What if the result is correct but the explanation is weak?

Treat it as partial success. Ask for a trace and change one boundary. A reliable model survives controlled variation.

Is the shortest solution the best?

Not automatically. Prefer the solution whose semantics, failure modes and maintenance cost are easiest to justify for the actual project.

When should official documentation be used?

Use it whenever syntax, supported types, SQL dialect behaviour or Git version details matter. Primary documentation settles the current contract.

How can a parent help without technical expertise?

Ask what was predicted, where the first difference appeared, what evidence matters and which smaller example could isolate it.

How do we test transfer?

Change the context, vocabulary and one boundary. Require the learner to identify the invariant before using a tool.

What should be saved after practice?

Keep the corrected rule, one trace, one boundary case and the next question. Avoid storing pages of unexplained output.

Can these exercises replace backups?

No. Use disposable examples and proper backups. Learning should not endanger schoolwork, repositories or personal data.

What counts as mastery?

The learner can predict, verify, diagnose, recover and justify a choice across more than one context, while knowing when to consult the current reference.

Official and supporting references

• Primary technical documentation for JavaScript Array.prototype.toSorted()
• eduKatePunggol: How Studying Works

Return to contents