PUNGGOL TUITION · PRACTICAL MASTERY GUIDE

If a learner has one large regular expression for an entire URL, small changes to a hostname, path or query can become surprisingly hard to explain. URLPattern offers a component-aware model for matching routes and extracting named groups.

The essential distinction is between test(), which returns a Boolean, and exec(), which returns component results and groups or null. Patterns can be constructed from a string or component object, relative strings need a base URL, matching is case-sensitive by default, and ignoreCase is an explicit option.

This guide treats JavaScript URLPattern as a reasoning skill. It begins with the governing model, moves through worked examples and diagnostic routes, and ends with transfer cases, practice with explained answers, parent decisions and FAQs. The examples are proposed home or lesson activities; they are not claims about a physical Punggol branch, school affiliation, timetable, class size, fee or guaranteed result.

For a Punggol family, the practical aim is simple: a learner should be able to use a short study block before schoolwork, after CCA, or during a weekend library session without needing a large project. Each chapter is designed so the smallest useful example can be completed, discussed and saved as a test fixture.

The official technical reference for this article is WHATWG URL Pattern Standard. Where the feature is version-sensitive or still developing, the article states that boundary explicitly. Examples were independently checked against the runtime or specification named in the reference section.

Choose a reading route

If the immediate concern is “I can copy the syntax but I cannot explain the result”, use the first route. If a real project is already failing, use the diagnostic route. Parents can use the final route to decide whether more practice, a smaller prerequisite or a different example is needed. For the wider learning framework, see How Studying Works.

Start from the model: Chapters 1–4. Begin with The component-wise model and continue in order to Base URLs for relative input.

Diagnose a confusing result: Chapters 5–8. Begin with test() answers a Boolean question and continue in order to Wildcards are intentionally broad.

Build reliable examples: Chapters 9–12. Begin with Hostname patterns and continue in order to Default case sensitivity.

Transfer to real work: Chapters 13–16. Begin with The ignoreCase option and continue in order to Regular-expression groups.

Decide and teach: Chapters 17–20. Begin with Invalid constructor input and continue in order to URLPattern or another tool.

Open the full 20-chapter index

1. 1. The component-wise model
2. 2. Constructing from a pattern string
3. 3. Constructing from an init object
4. 4. Base URLs for relative input
5. 5. test() answers a Boolean question
6. 6. exec() returns structured evidence
7. 7. Named pathname groups
8. 8. Wildcards are intentionally broad
9. 9. Hostname patterns
10. 10. Protocol and port constraints
11. 11. Search and hash components
12. 12. Default case sensitivity
13. 13. The ignoreCase option
14. 14. Missing component values
15. 15. URL parsing and normalisation
16. 16. Regular-expression groups
17. 17. Invalid constructor input
18. 18. Route-table ordering
19. 19. Runtime support and feature detection
20. 20. URLPattern or another tool

CHAPTER 1 OF 20 · Back to contents

1. The component-wise model

The short answer: The component-wise model is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: URLPattern matches URL components such as protocol, hostname, pathname, search and hash rather than one undifferentiated string.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “URLPattern matches URL components such as protocol, hostname, pathname, search and hash rather than one undifferentiated string.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the the component-wise model example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({pathname:'/books/:id'});
console.log(p.test('https://example.com/books/42'));

Expected result and reasoning. A supporting runtime prints true because the pathname component matches. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using one broad regular expression makes component boundaries and URL parsing easy to confuse. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which URL component carries the rule?”

• Evidence to collect: the exact input, environment version, observed result and the rule for the component-wise model
• Variable to hold constant: the surrounding setup, so the comparison isolates the component-wise model.
• Variable to change: add a hostname constraint
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For the component-wise model, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a revision-site router. Transfer the component-wise model into a revision-site router. Preserve the governing rule—URLPattern matches URL components such as protocol, hostname, pathname, search and hash rather than one undifferentiated string.—while identifying what changes in this setting. The component-wise model is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “URLPattern matches URL components such as protocol, hostname, pathname, search and hash rather than one undifferentiated string.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a book-catalogue route. Transfer the component-wise model into a book-catalogue route. Preserve the governing rule—URLPattern matches URL components such as protocol, hostname, pathname, search and hash rather than one undifferentiated string.—while identifying what changes in this setting. The component-wise model is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “URLPattern matches URL components such as protocol, hostname, pathname, search and hash rather than one undifferentiated string.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a service worker. Transfer the component-wise model into a service worker. Preserve the governing rule—URLPattern matches URL components such as protocol, hostname, pathname, search and hash rather than one undifferentiated string.—while identifying what changes in this setting. The component-wise model is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “URLPattern matches URL components such as protocol, hostname, pathname, search and hash rather than one undifferentiated string.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a browser-support test. Transfer the component-wise model into a browser-support test. Preserve the governing rule—URLPattern matches URL components such as protocol, hostname, pathname, search and hash rather than one undifferentiated string.—while identifying what changes in this setting. The component-wise model is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “URLPattern matches URL components such as protocol, hostname, pathname, search and hash rather than one undifferentiated string.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for the component-wise model, predict the result, then add a hostname constraint. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. A supporting runtime prints true because the pathname component matches. The contrast follows from this rule: URLPattern matches URL components such as protocol, hostname, pathname, search and hash rather than one undifferentiated string. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for the component-wise model, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain the component-wise model, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Contents · Full contents · Next: Constructing from a pattern string →

CHAPTER 2 OF 20 · Back to contents

2. Constructing from a pattern string

The short answer: Constructing from a pattern string is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: The URLPattern constructor can accept a pattern string, with a base URL when that pattern is relative.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “The URLPattern constructor can accept a pattern string, with a base URL when that pattern is relative.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the constructing from a pattern string example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern('/courses/:slug','https://example.com');
console.log(p.test('https://example.com/courses/css'));

Expected result and reasoning. The verified Node 24.19 fixture prints true. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. A relative pattern string without the required base cannot be resolved as intended. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Is the pattern absolute or relative?”

• Evidence to collect: the exact input, environment version, observed result and the rule for constructing from a pattern string
• Variable to hold constant: the surrounding setup, so the comparison isolates constructing from a pattern string.
• Variable to change: change the base hostname
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For constructing from a pattern string, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a school project dashboard. Transfer constructing from a pattern string into a school project dashboard. Preserve the governing rule—The URLPattern constructor can accept a pattern string, with a base URL when that pattern is relative.—while identifying what changes in this setting. Constructing from a pattern string is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The URLPattern constructor can accept a pattern string, with a base URL when that pattern is relative.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a form preview. Transfer constructing from a pattern string into a form preview. Preserve the governing rule—The URLPattern constructor can accept a pattern string, with a base URL when that pattern is relative.—while identifying what changes in this setting. Constructing from a pattern string is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The URLPattern constructor can accept a pattern string, with a base URL when that pattern is relative.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a link checker. Transfer constructing from a pattern string into a link checker. Preserve the governing rule—The URLPattern constructor can accept a pattern string, with a base URL when that pattern is relative.—while identifying what changes in this setting. Constructing from a pattern string is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The URLPattern constructor can accept a pattern string, with a base URL when that pattern is relative.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a route-table review. Transfer constructing from a pattern string into a route-table review. Preserve the governing rule—The URLPattern constructor can accept a pattern string, with a base URL when that pattern is relative.—while identifying what changes in this setting. Constructing from a pattern string is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The URLPattern constructor can accept a pattern string, with a base URL when that pattern is relative.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for constructing from a pattern string, predict the result, then change the base hostname. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified Node 24.19 fixture prints true. The contrast follows from this rule: The URLPattern constructor can accept a pattern string, with a base URL when that pattern is relative. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for constructing from a pattern string, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain constructing from a pattern string, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: The component-wise model · Full contents · Next: Constructing from an init object →

CHAPTER 3 OF 20 · Back to contents

3. Constructing from an init object

The short answer: Constructing from an init object is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: A URLPatternInit object states component patterns explicitly and leaves unrelated components unconstrained or defaulted by the API.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “A URLPatternInit object states component patterns explicitly and leaves unrelated components unconstrained or defaulted by the API.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the constructing from an init object example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({hostname:'*.example.com',pathname:'/help/:topic'});
console.log(p.test('https://docs.example.com/help/css'));

Expected result and reasoning. A supporting implementation reports true. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Putting hostname syntax inside pathname tests the wrong component. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which object key contains each condition?”

• Evidence to collect: the exact input, environment version, observed result and the rule for constructing from an init object
• Variable to hold constant: the surrounding setup, so the comparison isolates constructing from an init object.
• Variable to change: change only the hostname
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For constructing from an init object, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a book-catalogue route. Transfer constructing from an init object into a book-catalogue route. Preserve the governing rule—A URLPatternInit object states component patterns explicitly and leaves unrelated components unconstrained or defaulted by the API.—while identifying what changes in this setting. Constructing from an init object is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A URLPatternInit object states component patterns explicitly and leaves unrelated components unconstrained or defaulted by the API.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a service worker. Transfer constructing from an init object into a service worker. Preserve the governing rule—A URLPatternInit object states component patterns explicitly and leaves unrelated components unconstrained or defaulted by the API.—while identifying what changes in this setting. Constructing from an init object is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A URLPatternInit object states component patterns explicitly and leaves unrelated components unconstrained or defaulted by the API.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a browser-support test. Transfer constructing from an init object into a browser-support test. Preserve the governing rule—A URLPatternInit object states component patterns explicitly and leaves unrelated components unconstrained or defaulted by the API.—while identifying what changes in this setting. Constructing from an init object is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A URLPatternInit object states component patterns explicitly and leaves unrelated components unconstrained or defaulted by the API.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a revision-site router. Transfer constructing from an init object into a revision-site router. Preserve the governing rule—A URLPatternInit object states component patterns explicitly and leaves unrelated components unconstrained or defaulted by the API.—while identifying what changes in this setting. Constructing from an init object is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A URLPatternInit object states component patterns explicitly and leaves unrelated components unconstrained or defaulted by the API.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for constructing from an init object, predict the result, then change only the hostname. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. A supporting implementation reports true. The contrast follows from this rule: A URLPatternInit object states component patterns explicitly and leaves unrelated components unconstrained or defaulted by the API. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for constructing from an init object, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain constructing from an init object, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Constructing from a pattern string · Full contents · Next: Base URLs for relative input →

CHAPTER 4 OF 20 · Back to contents

4. Base URLs for relative input

The short answer: Base URLs for relative input is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: A base URL resolves a relative pattern or relative input before component matching.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “A base URL resolves a relative pattern or relative input before component matching.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the base urls for relative input example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern('/learn/:id','https://school.example');
console.log(p.exec('https://school.example/learn/7').pathname.groups.id);

Expected result and reasoning. The verified runtime prints 7. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Treating the base as a prefix string misses URL resolution rules. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What absolute URL results before matching?”

• Evidence to collect: the exact input, environment version, observed result and the rule for base urls for relative input
• Variable to hold constant: the surrounding setup, so the comparison isolates base urls for relative input.
• Variable to change: use a different base path and inspect resolution
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For base urls for relative input, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a form preview. Transfer base urls for relative input into a form preview. Preserve the governing rule—A base URL resolves a relative pattern or relative input before component matching.—while identifying what changes in this setting. Base URLs for relative input is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A base URL resolves a relative pattern or relative input before component matching.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a link checker. Transfer base urls for relative input into a link checker. Preserve the governing rule—A base URL resolves a relative pattern or relative input before component matching.—while identifying what changes in this setting. Base URLs for relative input is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A base URL resolves a relative pattern or relative input before component matching.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a route-table review. Transfer base urls for relative input into a route-table review. Preserve the governing rule—A base URL resolves a relative pattern or relative input before component matching.—while identifying what changes in this setting. Base URLs for relative input is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A base URL resolves a relative pattern or relative input before component matching.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a school project dashboard. Transfer base urls for relative input into a school project dashboard. Preserve the governing rule—A base URL resolves a relative pattern or relative input before component matching.—while identifying what changes in this setting. Base URLs for relative input is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A base URL resolves a relative pattern or relative input before component matching.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for base urls for relative input, predict the result, then use a different base path and inspect resolution. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified runtime prints 7. The contrast follows from this rule: A base URL resolves a relative pattern or relative input before component matching. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for base urls for relative input, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain base urls for relative input, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Constructing from an init object · Full contents · Next: test() answers a Boolean question →

CHAPTER 5 OF 20 · Back to contents

5. test() answers a Boolean question

The short answer: test() answers a Boolean question is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: test() reports whether the input matches component by component and does not return captured groups.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “test() reports whether the input matches component by component and does not return captured groups.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the test() answers a boolean question example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({pathname:'/books/:id'});
console.log(p.test('https://x.test/books/42'));

Expected result and reasoning. The verified runtime prints true. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Reading test() as a parser loses the distinction between a yes/no guard and extracted data. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Does the caller need a Boolean or captures?”

• Evidence to collect: the exact input, environment version, observed result and the rule for test() answers a boolean question
• Variable to hold constant: the surrounding setup, so the comparison isolates test() answers a boolean question.
• Variable to change: replace test with exec when the id is needed
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For test() answers a boolean question, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a service worker. Transfer test() answers a boolean question into a service worker. Preserve the governing rule—test() reports whether the input matches component by component and does not return captured groups.—while identifying what changes in this setting. test() answers a Boolean question is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “test() reports whether the input matches component by component and does not return captured groups.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a browser-support test. Transfer test() answers a boolean question into a browser-support test. Preserve the governing rule—test() reports whether the input matches component by component and does not return captured groups.—while identifying what changes in this setting. test() answers a Boolean question is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “test() reports whether the input matches component by component and does not return captured groups.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a revision-site router. Transfer test() answers a boolean question into a revision-site router. Preserve the governing rule—test() reports whether the input matches component by component and does not return captured groups.—while identifying what changes in this setting. test() answers a Boolean question is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “test() reports whether the input matches component by component and does not return captured groups.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a book-catalogue route. Transfer test() answers a boolean question into a book-catalogue route. Preserve the governing rule—test() reports whether the input matches component by component and does not return captured groups.—while identifying what changes in this setting. test() answers a Boolean question is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “test() reports whether the input matches component by component and does not return captured groups.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for test() answers a boolean question, predict the result, then replace test with exec when the id is needed. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified runtime prints true. The contrast follows from this rule: test() reports whether the input matches component by component and does not return captured groups. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for test() answers a boolean question, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain test() answers a boolean question, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Base URLs for relative input · Full contents · Next: exec() returns structured evidence →

CHAPTER 6 OF 20 · Back to contents

6. exec() returns structured evidence

The short answer: exec() returns structured evidence is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: exec() returns a URLPatternResult with component inputs and groups, or null when no match exists.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “exec() returns a URLPatternResult with component inputs and groups, or null when no match exists.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the exec() returns structured evidence example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({pathname:'/books/:id'});
const m=p.exec('https://x.test/books/42');
console.log(m.pathname.groups.id);

Expected result and reasoning. The verified Node fixture prints 42. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Dereferencing a null result turns a non-match into an unrelated TypeError. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Was the result checked before reading groups?”

• Evidence to collect: the exact input, environment version, observed result and the rule for exec() returns structured evidence
• Variable to hold constant: the surrounding setup, so the comparison isolates exec() returns structured evidence.
• Variable to change: test a non-matching /authors/42 URL
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For exec() returns structured evidence, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a link checker. Transfer exec() returns structured evidence into a link checker. Preserve the governing rule—exec() returns a URLPatternResult with component inputs and groups, or null when no match exists.—while identifying what changes in this setting. exec() returns structured evidence is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “exec() returns a URLPatternResult with component inputs and groups, or null when no match exists.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a route-table review. Transfer exec() returns structured evidence into a route-table review. Preserve the governing rule—exec() returns a URLPatternResult with component inputs and groups, or null when no match exists.—while identifying what changes in this setting. exec() returns structured evidence is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “exec() returns a URLPatternResult with component inputs and groups, or null when no match exists.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a school project dashboard. Transfer exec() returns structured evidence into a school project dashboard. Preserve the governing rule—exec() returns a URLPatternResult with component inputs and groups, or null when no match exists.—while identifying what changes in this setting. exec() returns structured evidence is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “exec() returns a URLPatternResult with component inputs and groups, or null when no match exists.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a form preview. Transfer exec() returns structured evidence into a form preview. Preserve the governing rule—exec() returns a URLPatternResult with component inputs and groups, or null when no match exists.—while identifying what changes in this setting. exec() returns structured evidence is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “exec() returns a URLPatternResult with component inputs and groups, or null when no match exists.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for exec() returns structured evidence, predict the result, then test a non-matching /authors/42 URL. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified Node fixture prints 42. The contrast follows from this rule: exec() returns a URLPatternResult with component inputs and groups, or null when no match exists. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for exec() returns structured evidence, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain exec() returns structured evidence, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: test() answers a Boolean question · Full contents · Next: Named pathname groups →

CHAPTER 7 OF 20 · Back to contents

7. Named pathname groups

The short answer: Named pathname groups is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: A :name token captures the corresponding pathname segment under that name.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “A :name token captures the corresponding pathname segment under that name.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the named pathname groups example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({pathname:'/students/:studentId'});
console.log(p.exec('https://x.test/students/308').pathname.groups.studentId);

Expected result and reasoning. The captured string is 308. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Expecting a number ignores that route captures are text requiring separate validation. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What validation must follow capture extraction?”

• Evidence to collect: the exact input, environment version, observed result and the rule for named pathname groups
• Variable to hold constant: the surrounding setup, so the comparison isolates named pathname groups.
• Variable to change: reject a non-numeric captured id explicitly
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For named pathname groups, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a browser-support test. Transfer named pathname groups into a browser-support test. Preserve the governing rule—A :name token captures the corresponding pathname segment under that name.—while identifying what changes in this setting. Named pathname groups is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A :name token captures the corresponding pathname segment under that name.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a revision-site router. Transfer named pathname groups into a revision-site router. Preserve the governing rule—A :name token captures the corresponding pathname segment under that name.—while identifying what changes in this setting. Named pathname groups is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A :name token captures the corresponding pathname segment under that name.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a book-catalogue route. Transfer named pathname groups into a book-catalogue route. Preserve the governing rule—A :name token captures the corresponding pathname segment under that name.—while identifying what changes in this setting. Named pathname groups is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A :name token captures the corresponding pathname segment under that name.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a service worker. Transfer named pathname groups into a service worker. Preserve the governing rule—A :name token captures the corresponding pathname segment under that name.—while identifying what changes in this setting. Named pathname groups is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A :name token captures the corresponding pathname segment under that name.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for named pathname groups, predict the result, then reject a non-numeric captured id explicitly. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The captured string is 308. The contrast follows from this rule: A :name token captures the corresponding pathname segment under that name. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for named pathname groups, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain named pathname groups, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: exec() returns structured evidence · Full contents · Next: Wildcards are intentionally broad →

CHAPTER 8 OF 20 · Back to contents

8. Wildcards are intentionally broad

The short answer: Wildcards are intentionally broad is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: A wildcard can capture a broader remainder and should be ordered after more specific routes.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “A wildcard can capture a broader remainder and should be ordered after more specific routes.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the wildcards are intentionally broad example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({pathname:'/files/*'});
console.log(p.test('https://x.test/files/a/b.txt'));

Expected result and reasoning. A supporting implementation matches the nested remainder. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Placing a wildcard route first can shadow a more specific route in application code. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which route wins when several patterns match?”

• Evidence to collect: the exact input, environment version, observed result and the rule for wildcards are intentionally broad
• Variable to hold constant: the surrounding setup, so the comparison isolates wildcards are intentionally broad.
• Variable to change: move a specific /files/public/:id route first
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For wildcards are intentionally broad, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a route-table review. Transfer wildcards are intentionally broad into a route-table review. Preserve the governing rule—A wildcard can capture a broader remainder and should be ordered after more specific routes.—while identifying what changes in this setting. Wildcards are intentionally broad is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A wildcard can capture a broader remainder and should be ordered after more specific routes.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a school project dashboard. Transfer wildcards are intentionally broad into a school project dashboard. Preserve the governing rule—A wildcard can capture a broader remainder and should be ordered after more specific routes.—while identifying what changes in this setting. Wildcards are intentionally broad is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A wildcard can capture a broader remainder and should be ordered after more specific routes.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a form preview. Transfer wildcards are intentionally broad into a form preview. Preserve the governing rule—A wildcard can capture a broader remainder and should be ordered after more specific routes.—while identifying what changes in this setting. Wildcards are intentionally broad is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A wildcard can capture a broader remainder and should be ordered after more specific routes.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a link checker. Transfer wildcards are intentionally broad into a link checker. Preserve the governing rule—A wildcard can capture a broader remainder and should be ordered after more specific routes.—while identifying what changes in this setting. Wildcards are intentionally broad is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A wildcard can capture a broader remainder and should be ordered after more specific routes.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for wildcards are intentionally broad, predict the result, then move a specific /files/public/:id route first. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. A supporting implementation matches the nested remainder. The contrast follows from this rule: A wildcard can capture a broader remainder and should be ordered after more specific routes. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for wildcards are intentionally broad, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain wildcards are intentionally broad, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Named pathname groups · Full contents · Next: Hostname patterns →

CHAPTER 9 OF 20 · Back to contents

9. Hostname patterns

The short answer: Hostname patterns is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: Hostname matching is expressed in the hostname component and follows URLPattern syntax.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “Hostname matching is expressed in the hostname component and follows URLPattern syntax.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the hostname patterns example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({hostname:'*.example.com'});
console.log(p.test('https://learn.example.com/'));

Expected result and reasoning. The subdomain input matches. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. A star accepted without a security review may cover hosts the application did not intend. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What host set does the pattern authorise?”

• Evidence to collect: the exact input, environment version, observed result and the rule for hostname patterns
• Variable to hold constant: the surrounding setup, so the comparison isolates hostname patterns.
• Variable to change: add a pathname constraint and a negative host case
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For hostname patterns, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a revision-site router. Transfer hostname patterns into a revision-site router. Preserve the governing rule—Hostname matching is expressed in the hostname component and follows URLPattern syntax.—while identifying what changes in this setting. Hostname patterns is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Hostname matching is expressed in the hostname component and follows URLPattern syntax.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a book-catalogue route. Transfer hostname patterns into a book-catalogue route. Preserve the governing rule—Hostname matching is expressed in the hostname component and follows URLPattern syntax.—while identifying what changes in this setting. Hostname patterns is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Hostname matching is expressed in the hostname component and follows URLPattern syntax.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a service worker. Transfer hostname patterns into a service worker. Preserve the governing rule—Hostname matching is expressed in the hostname component and follows URLPattern syntax.—while identifying what changes in this setting. Hostname patterns is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Hostname matching is expressed in the hostname component and follows URLPattern syntax.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a browser-support test. Transfer hostname patterns into a browser-support test. Preserve the governing rule—Hostname matching is expressed in the hostname component and follows URLPattern syntax.—while identifying what changes in this setting. Hostname patterns is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Hostname matching is expressed in the hostname component and follows URLPattern syntax.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for hostname patterns, predict the result, then add a pathname constraint and a negative host case. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The subdomain input matches. The contrast follows from this rule: Hostname matching is expressed in the hostname component and follows URLPattern syntax. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for hostname patterns, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain hostname patterns, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Wildcards are intentionally broad · Full contents · Next: Protocol and port constraints →

CHAPTER 10 OF 20 · Back to contents

10. Protocol and port constraints

The short answer: Protocol and port constraints is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: Protocol and port can be matched separately from host and path.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “Protocol and port can be matched separately from host and path.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the protocol and port constraints example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({protocol:'https',port:'8443'});
console.log(p.test('https://example.com:8443/x'));

Expected result and reasoning. The matching scheme and port produce true. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Checking only hostname can accept the wrong transport or service port. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which components are security-relevant for this route?”

• Evidence to collect: the exact input, environment version, observed result and the rule for protocol and port constraints
• Variable to hold constant: the surrounding setup, so the comparison isolates protocol and port constraints.
• Variable to change: change the port to 443
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For protocol and port constraints, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a school project dashboard. Transfer protocol and port constraints into a school project dashboard. Preserve the governing rule—Protocol and port can be matched separately from host and path.—while identifying what changes in this setting. Protocol and port constraints is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Protocol and port can be matched separately from host and path.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a form preview. Transfer protocol and port constraints into a form preview. Preserve the governing rule—Protocol and port can be matched separately from host and path.—while identifying what changes in this setting. Protocol and port constraints is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Protocol and port can be matched separately from host and path.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a link checker. Transfer protocol and port constraints into a link checker. Preserve the governing rule—Protocol and port can be matched separately from host and path.—while identifying what changes in this setting. Protocol and port constraints is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Protocol and port can be matched separately from host and path.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a route-table review. Transfer protocol and port constraints into a route-table review. Preserve the governing rule—Protocol and port can be matched separately from host and path.—while identifying what changes in this setting. Protocol and port constraints is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Protocol and port can be matched separately from host and path.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for protocol and port constraints, predict the result, then change the port to 443. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The matching scheme and port produce true. The contrast follows from this rule: Protocol and port can be matched separately from host and path. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for protocol and port constraints, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain protocol and port constraints, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Hostname patterns · Full contents · Next: Search and hash components →

CHAPTER 11 OF 20 · Back to contents

11. Search and hash components

The short answer: Search and hash components is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: Query and fragment patterns belong to search and hash components rather than pathname.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “Query and fragment patterns belong to search and hash components rather than pathname.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the search and hash components example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({pathname:'/find',search:'q=:term'});
console.log(p.test('https://x.test/find?q=css'));

Expected result and reasoning. A supporting implementation matches the separated path and search components. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Embedding ?q= inside pathname contradicts URL component parsing. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Where did the URL parser place the question-mark content?”

• Evidence to collect: the exact input, environment version, observed result and the rule for search and hash components
• Variable to hold constant: the surrounding setup, so the comparison isolates search and hash components.
• Variable to change: add a hash pattern separately
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For search and hash components, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a book-catalogue route. Transfer search and hash components into a book-catalogue route. Preserve the governing rule—Query and fragment patterns belong to search and hash components rather than pathname.—while identifying what changes in this setting. Search and hash components is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Query and fragment patterns belong to search and hash components rather than pathname.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a service worker. Transfer search and hash components into a service worker. Preserve the governing rule—Query and fragment patterns belong to search and hash components rather than pathname.—while identifying what changes in this setting. Search and hash components is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Query and fragment patterns belong to search and hash components rather than pathname.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a browser-support test. Transfer search and hash components into a browser-support test. Preserve the governing rule—Query and fragment patterns belong to search and hash components rather than pathname.—while identifying what changes in this setting. Search and hash components is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Query and fragment patterns belong to search and hash components rather than pathname.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a revision-site router. Transfer search and hash components into a revision-site router. Preserve the governing rule—Query and fragment patterns belong to search and hash components rather than pathname.—while identifying what changes in this setting. Search and hash components is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Query and fragment patterns belong to search and hash components rather than pathname.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for search and hash components, predict the result, then add a hash pattern separately. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. A supporting implementation matches the separated path and search components. The contrast follows from this rule: Query and fragment patterns belong to search and hash components rather than pathname. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for search and hash components, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain search and hash components, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Protocol and port constraints · Full contents · Next: Default case sensitivity →

CHAPTER 12 OF 20 · Back to contents

12. Default case sensitivity

The short answer: Default case sensitivity is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: Without options, URLPattern matching is case-sensitive.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “Without options, URLPattern matching is case-sensitive.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the default case sensitivity example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({pathname:'/Books/:id'});
console.log(p.test('https://x.test/books/9'));

Expected result and reasoning. The verified runtime prints false. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming web paths are universally case-insensitive changes routing policy silently. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Is the difference in spelling intentional?”

• Evidence to collect: the exact input, environment version, observed result and the rule for default case sensitivity
• Variable to hold constant: the surrounding setup, so the comparison isolates default case sensitivity.
• Variable to change: match /Books/9 exactly
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For default case sensitivity, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a form preview. Transfer default case sensitivity into a form preview. Preserve the governing rule—Without options, URLPattern matching is case-sensitive.—while identifying what changes in this setting. Default case sensitivity is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Without options, URLPattern matching is case-sensitive.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a link checker. Transfer default case sensitivity into a link checker. Preserve the governing rule—Without options, URLPattern matching is case-sensitive.—while identifying what changes in this setting. Default case sensitivity is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Without options, URLPattern matching is case-sensitive.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a route-table review. Transfer default case sensitivity into a route-table review. Preserve the governing rule—Without options, URLPattern matching is case-sensitive.—while identifying what changes in this setting. Default case sensitivity is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Without options, URLPattern matching is case-sensitive.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a school project dashboard. Transfer default case sensitivity into a school project dashboard. Preserve the governing rule—Without options, URLPattern matching is case-sensitive.—while identifying what changes in this setting. Default case sensitivity is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Without options, URLPattern matching is case-sensitive.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for default case sensitivity, predict the result, then match /Books/9 exactly. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified runtime prints false. The contrast follows from this rule: Without options, URLPattern matching is case-sensitive. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for default case sensitivity, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain default case sensitivity, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Search and hash components · Full contents · Next: The ignoreCase option →

CHAPTER 13 OF 20 · Back to contents

13. The ignoreCase option

The short answer: The ignoreCase option is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: The constructor option {ignoreCase:true} requests case-insensitive matching.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “The constructor option {ignoreCase:true} requests case-insensitive matching.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the the ignorecase option example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({pathname:'/Books/:id'},{ignoreCase:true});
console.log(p.test('https://x.test/books/9'));

Expected result and reasoning. The verified Node 24.19 fixture accepts the lowercase pathname because ignoreCase was enabled explicitly. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Lowercasing raw URLs before parsing can change or obscure preserved data. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Can the matching policy be stated at construction?”

• Evidence to collect: the exact input, environment version, observed result and the rule for the ignorecase option
• Variable to hold constant: the surrounding setup, so the comparison isolates the ignorecase option.
• Variable to change: remove the option and compare
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For the ignorecase option, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a service worker. Transfer the ignorecase option into a service worker. Preserve the governing rule—The constructor option {ignoreCase:true} requests case-insensitive matching.—while identifying what changes in this setting. The ignoreCase option is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The constructor option {ignoreCase:true} requests case-insensitive matching.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a browser-support test. Transfer the ignorecase option into a browser-support test. Preserve the governing rule—The constructor option {ignoreCase:true} requests case-insensitive matching.—while identifying what changes in this setting. The ignoreCase option is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The constructor option {ignoreCase:true} requests case-insensitive matching.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a revision-site router. Transfer the ignorecase option into a revision-site router. Preserve the governing rule—The constructor option {ignoreCase:true} requests case-insensitive matching.—while identifying what changes in this setting. The ignoreCase option is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The constructor option {ignoreCase:true} requests case-insensitive matching.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a book-catalogue route. Transfer the ignorecase option into a book-catalogue route. Preserve the governing rule—The constructor option {ignoreCase:true} requests case-insensitive matching.—while identifying what changes in this setting. The ignoreCase option is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The constructor option {ignoreCase:true} requests case-insensitive matching.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for the ignorecase option, predict the result, then remove the option and compare. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified Node 24.19 fixture accepts the lowercase pathname because ignoreCase was enabled explicitly. The contrast follows from this rule: The constructor option {ignoreCase:true} requests case-insensitive matching. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for the ignorecase option, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain the ignorecase option, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Default case sensitivity · Full contents · Next: Missing component values →

CHAPTER 14 OF 20 · Back to contents

14. Missing component values

The short answer: Missing component values is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: A URLPatternInit input can omit components; the standard defines how missing values are processed rather than inventing arbitrary text.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “A URLPatternInit input can omit components; the standard defines how missing values are processed rather than inventing arbitrary text.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the missing component values example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({pathname:'/a'});
console.log(p.test({pathname:'/a'}));

Expected result and reasoning. A supporting implementation can match the supplied pathname-only input. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming every missing component equals the current page URL creates hidden ambient state. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which components were supplied explicitly?”

• Evidence to collect: the exact input, environment version, observed result and the rule for missing component values
• Variable to hold constant: the surrounding setup, so the comparison isolates missing component values.
• Variable to change: add an explicit hostname pattern
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For missing component values, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a link checker. Transfer missing component values into a link checker. Preserve the governing rule—A URLPatternInit input can omit components; the standard defines how missing values are processed rather than inventing arbitrary text.—while identifying what changes in this setting. Missing component values is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A URLPatternInit input can omit components; the standard defines how missing values are processed rather than inventing arbitrary text.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a route-table review. Transfer missing component values into a route-table review. Preserve the governing rule—A URLPatternInit input can omit components; the standard defines how missing values are processed rather than inventing arbitrary text.—while identifying what changes in this setting. Missing component values is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A URLPatternInit input can omit components; the standard defines how missing values are processed rather than inventing arbitrary text.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a school project dashboard. Transfer missing component values into a school project dashboard. Preserve the governing rule—A URLPatternInit input can omit components; the standard defines how missing values are processed rather than inventing arbitrary text.—while identifying what changes in this setting. Missing component values is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A URLPatternInit input can omit components; the standard defines how missing values are processed rather than inventing arbitrary text.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a form preview. Transfer missing component values into a form preview. Preserve the governing rule—A URLPatternInit input can omit components; the standard defines how missing values are processed rather than inventing arbitrary text.—while identifying what changes in this setting. Missing component values is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A URLPatternInit input can omit components; the standard defines how missing values are processed rather than inventing arbitrary text.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for missing component values, predict the result, then add an explicit hostname pattern. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. A supporting implementation can match the supplied pathname-only input. The contrast follows from this rule: A URLPatternInit input can omit components; the standard defines how missing values are processed rather than inventing arbitrary text. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for missing component values, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain missing component values, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: The ignoreCase option · Full contents · Next: URL parsing and normalisation →

CHAPTER 15 OF 20 · Back to contents

15. URL parsing and normalisation

The short answer: URL parsing and normalisation is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: Inputs are processed as URLs before pattern components are compared, so use URL semantics rather than raw-string intuition.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “Inputs are processed as URLs before pattern components are compared, so use URL semantics rather than raw-string intuition.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the url parsing and normalisation example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({pathname:'/a/b'});
console.log(p.test('https://x.test/a/./b'));

Expected result and reasoning. The result follows the implementation’s standard URL parsing and normalisation before matching. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Comparing the visible source text character by character ignores URL processing. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What is the parsed pathname after URL construction?”

• Evidence to collect: the exact input, environment version, observed result and the rule for url parsing and normalisation
• Variable to hold constant: the surrounding setup, so the comparison isolates url parsing and normalisation.
• Variable to change: print new URL(input).pathname beside the result
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For url parsing and normalisation, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a browser-support test. Transfer url parsing and normalisation into a browser-support test. Preserve the governing rule—Inputs are processed as URLs before pattern components are compared, so use URL semantics rather than raw-string intuition.—while identifying what changes in this setting. URL parsing and normalisation is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Inputs are processed as URLs before pattern components are compared, so use URL semantics rather than raw-string intuition.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a revision-site router. Transfer url parsing and normalisation into a revision-site router. Preserve the governing rule—Inputs are processed as URLs before pattern components are compared, so use URL semantics rather than raw-string intuition.—while identifying what changes in this setting. URL parsing and normalisation is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Inputs are processed as URLs before pattern components are compared, so use URL semantics rather than raw-string intuition.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a book-catalogue route. Transfer url parsing and normalisation into a book-catalogue route. Preserve the governing rule—Inputs are processed as URLs before pattern components are compared, so use URL semantics rather than raw-string intuition.—while identifying what changes in this setting. URL parsing and normalisation is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Inputs are processed as URLs before pattern components are compared, so use URL semantics rather than raw-string intuition.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a service worker. Transfer url parsing and normalisation into a service worker. Preserve the governing rule—Inputs are processed as URLs before pattern components are compared, so use URL semantics rather than raw-string intuition.—while identifying what changes in this setting. URL parsing and normalisation is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Inputs are processed as URLs before pattern components are compared, so use URL semantics rather than raw-string intuition.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for url parsing and normalisation, predict the result, then print new URL(input).pathname beside the result. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The result follows the implementation’s standard URL parsing and normalisation before matching. The contrast follows from this rule: Inputs are processed as URLs before pattern components are compared, so use URL semantics rather than raw-string intuition. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for url parsing and normalisation, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain url parsing and normalisation, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Missing component values · Full contents · Next: Regular-expression groups →

CHAPTER 16 OF 20 · Back to contents

16. Regular-expression groups

The short answer: Regular-expression groups is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: Patterns may contain regular-expression groups; hasRegExpGroups reports whether such groups occur.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “Patterns may contain regular-expression groups; hasRegExpGroups reports whether such groups occur.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the regular-expression groups example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const p=new URLPattern({pathname:'/item/(\d+)'});
console.log(p.hasRegExpGroups);

Expected result and reasoning. A supporting implementation reports true for a regex-group pattern. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using complex regex fragments where named tokens suffice raises review and maintenance cost. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Does the pattern need regex power or only a named segment?”

• Evidence to collect: the exact input, environment version, observed result and the rule for regular-expression groups
• Variable to hold constant: the surrounding setup, so the comparison isolates regular-expression groups.
• Variable to change: rewrite a simple case with :id
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For regular-expression groups, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a route-table review. Transfer regular-expression groups into a route-table review. Preserve the governing rule—Patterns may contain regular-expression groups; hasRegExpGroups reports whether such groups occur.—while identifying what changes in this setting. Regular-expression groups is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Patterns may contain regular-expression groups; hasRegExpGroups reports whether such groups occur.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a school project dashboard. Transfer regular-expression groups into a school project dashboard. Preserve the governing rule—Patterns may contain regular-expression groups; hasRegExpGroups reports whether such groups occur.—while identifying what changes in this setting. Regular-expression groups is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Patterns may contain regular-expression groups; hasRegExpGroups reports whether such groups occur.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a form preview. Transfer regular-expression groups into a form preview. Preserve the governing rule—Patterns may contain regular-expression groups; hasRegExpGroups reports whether such groups occur.—while identifying what changes in this setting. Regular-expression groups is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Patterns may contain regular-expression groups; hasRegExpGroups reports whether such groups occur.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a link checker. Transfer regular-expression groups into a link checker. Preserve the governing rule—Patterns may contain regular-expression groups; hasRegExpGroups reports whether such groups occur.—while identifying what changes in this setting. Regular-expression groups is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Patterns may contain regular-expression groups; hasRegExpGroups reports whether such groups occur.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for regular-expression groups, predict the result, then rewrite a simple case with :id. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. A supporting implementation reports true for a regex-group pattern. The contrast follows from this rule: Patterns may contain regular-expression groups; hasRegExpGroups reports whether such groups occur. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for regular-expression groups, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain regular-expression groups, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: URL parsing and normalisation · Full contents · Next: Invalid constructor input →

CHAPTER 17 OF 20 · Back to contents

17. Invalid constructor input

The short answer: Invalid constructor input is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: Malformed pattern input can make construction throw, so configuration should be validated at a clear boundary.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “Malformed pattern input can make construction throw, so configuration should be validated at a clear boundary.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the invalid constructor input example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

try { new URLPattern('['); } catch (e) { console.log(e.name); }

Expected result and reasoning. A supporting implementation reports a constructor error rather than a normal non-match. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Catching every error around routing can hide a broken pattern as if the URL simply did not match. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Did construction fail or did test() return false?”

• Evidence to collect: the exact input, environment version, observed result and the rule for invalid constructor input
• Variable to hold constant: the surrounding setup, so the comparison isolates invalid constructor input.
• Variable to change: construct patterns once at startup
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For invalid constructor input, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a revision-site router. Transfer invalid constructor input into a revision-site router. Preserve the governing rule—Malformed pattern input can make construction throw, so configuration should be validated at a clear boundary.—while identifying what changes in this setting. Invalid constructor input is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Malformed pattern input can make construction throw, so configuration should be validated at a clear boundary.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a book-catalogue route. Transfer invalid constructor input into a book-catalogue route. Preserve the governing rule—Malformed pattern input can make construction throw, so configuration should be validated at a clear boundary.—while identifying what changes in this setting. Invalid constructor input is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Malformed pattern input can make construction throw, so configuration should be validated at a clear boundary.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a service worker. Transfer invalid constructor input into a service worker. Preserve the governing rule—Malformed pattern input can make construction throw, so configuration should be validated at a clear boundary.—while identifying what changes in this setting. Invalid constructor input is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Malformed pattern input can make construction throw, so configuration should be validated at a clear boundary.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a browser-support test. Transfer invalid constructor input into a browser-support test. Preserve the governing rule—Malformed pattern input can make construction throw, so configuration should be validated at a clear boundary.—while identifying what changes in this setting. Invalid constructor input is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Malformed pattern input can make construction throw, so configuration should be validated at a clear boundary.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for invalid constructor input, predict the result, then construct patterns once at startup. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. A supporting implementation reports a constructor error rather than a normal non-match. The contrast follows from this rule: Malformed pattern input can make construction throw, so configuration should be validated at a clear boundary. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for invalid constructor input, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain invalid constructor input, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Regular-expression groups · Full contents · Next: Route-table ordering →

CHAPTER 18 OF 20 · Back to contents

18. Route-table ordering

The short answer: Route-table ordering is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: URLPattern evaluates one pattern at a time; application code decides priority when several entries match.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “URLPattern evaluates one pattern at a time; application code decides priority when several entries match.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the route-table ordering example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const routes=[new URLPattern({pathname:'/files/public/:id'}),new URLPattern({pathname:'/files/*'})];
console.log(routes.findIndex(p=>p.test('https://x.test/files/public/7')));

Expected result and reasoning. The specific-first table selects index 0. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Treating patterns as automatically ranked lets a broad entry steal requests. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What explicit ordering policy does the route table use?”

• Evidence to collect: the exact input, environment version, observed result and the rule for route-table ordering
• Variable to hold constant: the surrounding setup, so the comparison isolates route-table ordering.
• Variable to change: reverse the array and observe the collision
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For route-table ordering, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a school project dashboard. Transfer route-table ordering into a school project dashboard. Preserve the governing rule—URLPattern evaluates one pattern at a time; application code decides priority when several entries match.—while identifying what changes in this setting. Route-table ordering is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “URLPattern evaluates one pattern at a time; application code decides priority when several entries match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a form preview. Transfer route-table ordering into a form preview. Preserve the governing rule—URLPattern evaluates one pattern at a time; application code decides priority when several entries match.—while identifying what changes in this setting. Route-table ordering is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “URLPattern evaluates one pattern at a time; application code decides priority when several entries match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a link checker. Transfer route-table ordering into a link checker. Preserve the governing rule—URLPattern evaluates one pattern at a time; application code decides priority when several entries match.—while identifying what changes in this setting. Route-table ordering is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “URLPattern evaluates one pattern at a time; application code decides priority when several entries match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a route-table review. Transfer route-table ordering into a route-table review. Preserve the governing rule—URLPattern evaluates one pattern at a time; application code decides priority when several entries match.—while identifying what changes in this setting. Route-table ordering is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “URLPattern evaluates one pattern at a time; application code decides priority when several entries match.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for route-table ordering, predict the result, then reverse the array and observe the collision. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The specific-first table selects index 0. The contrast follows from this rule: URLPattern evaluates one pattern at a time; application code decides priority when several entries match. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for route-table ordering, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain route-table ordering, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Invalid constructor input · Full contents · Next: Runtime support and feature detection →

CHAPTER 19 OF 20 · Back to contents

19. Runtime support and feature detection

The short answer: Runtime support and feature detection is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: Code should verify URLPattern support in its target runtimes or load a deliberately tested alternative.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “Code should verify URLPattern support in its target runtimes or load a deliberately tested alternative.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the runtime support and feature detection example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

console.log(typeof URLPattern === 'function');

Expected result and reasoning. The verified Node 24.19 environment prints true, but support must be checked for the actual browser or runtime target. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. One successful laptop test is not a universal compatibility claim. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which deployment environments are in the support matrix?”

• Evidence to collect: the exact input, environment version, observed result and the rule for runtime support and feature detection
• Variable to hold constant: the surrounding setup, so the comparison isolates runtime support and feature detection.
• Variable to change: run the fixture in every declared target
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For runtime support and feature detection, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a book-catalogue route. Transfer runtime support and feature detection into a book-catalogue route. Preserve the governing rule—Code should verify URLPattern support in its target runtimes or load a deliberately tested alternative.—while identifying what changes in this setting. Runtime support and feature detection is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Code should verify URLPattern support in its target runtimes or load a deliberately tested alternative.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a service worker. Transfer runtime support and feature detection into a service worker. Preserve the governing rule—Code should verify URLPattern support in its target runtimes or load a deliberately tested alternative.—while identifying what changes in this setting. Runtime support and feature detection is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Code should verify URLPattern support in its target runtimes or load a deliberately tested alternative.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a browser-support test. Transfer runtime support and feature detection into a browser-support test. Preserve the governing rule—Code should verify URLPattern support in its target runtimes or load a deliberately tested alternative.—while identifying what changes in this setting. Runtime support and feature detection is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Code should verify URLPattern support in its target runtimes or load a deliberately tested alternative.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a revision-site router. Transfer runtime support and feature detection into a revision-site router. Preserve the governing rule—Code should verify URLPattern support in its target runtimes or load a deliberately tested alternative.—while identifying what changes in this setting. Runtime support and feature detection is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Code should verify URLPattern support in its target runtimes or load a deliberately tested alternative.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for runtime support and feature detection, predict the result, then run the fixture in every declared target. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified Node 24.19 environment prints true, but support must be checked for the actual browser or runtime target. The contrast follows from this rule: Code should verify URLPattern support in its target runtimes or load a deliberately tested alternative. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for runtime support and feature detection, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain runtime support and feature detection, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Route-table ordering · Full contents · Next: URLPattern or another tool →

CHAPTER 20 OF 20 · Back to contents

20. URLPattern or another tool

The short answer: URLPattern or another tool is a decision about the feature’s documented contract, not a cue to copy a longer snippet. The governing rule is: Use URLPattern for declarative component-aware matching; use URL for parsing and validation, or RegExp for a non-URL text language.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The platform applies the rule “Use URLPattern for declarative component-aware matching; use URL for parsing and validation, or RegExp for a non-URL text language.”. A minimal fixture makes the relevant input and observation visible while keeping unrelated project state out of the explanation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the urlpattern or another tool example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

const u=new URL('https://x.test/books/42');
const route=new URLPattern({pathname:'/books/:id'});
console.log(route.exec(u.href).pathname.groups.id);

Expected result and reasoning. The two APIs cooperate: URL represents the URL and URLPattern classifies the route. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Forcing URLPattern to validate business rules for the captured id stretches its contract. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Is the job URL parsing, route matching or domain validation?”

• Evidence to collect: the exact input, environment version, observed result and the rule for urlpattern or another tool
• Variable to hold constant: the surrounding setup, so the comparison isolates urlpattern or another tool.
• Variable to change: validate the captured id in a separate step
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For urlpattern or another tool, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a form preview. Transfer urlpattern or another tool into a form preview. Preserve the governing rule—Use URLPattern for declarative component-aware matching; use URL for parsing and validation, or RegExp for a non-URL text language.—while identifying what changes in this setting. URLPattern or another tool is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use URLPattern for declarative component-aware matching; use URL for parsing and validation, or RegExp for a non-URL text language.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a link checker. Transfer urlpattern or another tool into a link checker. Preserve the governing rule—Use URLPattern for declarative component-aware matching; use URL for parsing and validation, or RegExp for a non-URL text language.—while identifying what changes in this setting. URLPattern or another tool is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use URLPattern for declarative component-aware matching; use URL for parsing and validation, or RegExp for a non-URL text language.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a route-table review. Transfer urlpattern or another tool into a route-table review. Preserve the governing rule—Use URLPattern for declarative component-aware matching; use URL for parsing and validation, or RegExp for a non-URL text language.—while identifying what changes in this setting. URLPattern or another tool is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use URLPattern for declarative component-aware matching; use URL for parsing and validation, or RegExp for a non-URL text language.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a school project dashboard. Transfer urlpattern or another tool into a school project dashboard. Preserve the governing rule—Use URLPattern for declarative component-aware matching; use URL for parsing and validation, or RegExp for a non-URL text language.—while identifying what changes in this setting. URLPattern or another tool is a decision about the feature’s documented contract, not a cue to copy a longer snippet. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use URLPattern for declarative component-aware matching; use URL for parsing and validation, or RegExp for a non-URL text language.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for urlpattern or another tool, predict the result, then validate the captured id in a separate step. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The two APIs cooperate: URL represents the URL and URLPattern classifies the route. The contrast follows from this rule: Use URLPattern for declarative component-aware matching; use URL for parsing and validation, or RegExp for a non-URL text language. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for urlpattern or another tool, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain urlpattern or another tool, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Runtime support and feature detection · Full contents · Parent guide →

Parent guide: what mastery looks like

A learner has not mastered JavaScript URLPattern merely because one polished example runs. Look for four behaviours: they can state the rule in plain language; predict before executing; isolate one changed condition; and explain why a transfer case is the same problem or a different one. Those behaviours make progress visible without requiring a parent to become a specialist.

Use a ten-minute check-in. Ask the learner to choose one chapter, reconstruct its example from memory, and narrate the causal chain. Then change one input. If the learner can update the prediction and justify the change, stop. More repetitions are not automatically better. Save the two-case pair and return to it after a few days.

If every answer is hesitant, reduce the scope. Return to the earliest chapter whose rule cannot be stated accurately. If explanations are fluent but real tasks still fail, move to a capstone because the missing skill is likely transfer or diagnosis. If frustration rises, separate typing errors from conceptual errors and solve only one category in that session.

Capstone practice with explained routes

Capstone 1: Rebuild the smallest trustworthy fixture

Scenario. Create a disposable JavaScript fixture that demonstrates component-aware URL route matching without unrelated project code.

Route. Record environment, input, prediction and output. Keep one nearby contrast. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The fixture succeeds when another learner can reproduce the observation and explain the rule separating the two cases. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 2: Diagnose a believable wrong explanation

Scenario. A learner has the correct output but explains it with the wrong mechanism.

Route. Change the one condition the wrong explanation says matters while holding the real governing condition constant. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The controlled contrast exposes the misconception without turning the task into guesswork. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 3: Handle a version boundary

Scenario. Two environments produce different observations.

Route. Capture versions, platform or browser, exact input and relevant state before comparing. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. A difference is not automatically an error; bind the claim to the documented environment and retest. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 4: Design a parent check-in

Scenario. A parent has ten minutes and no specialist background.

Route. Ask for one rule, one prediction, one run and one changed condition. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The learner demonstrates mastery through a causal explanation and evidence-based revision. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 5: Transfer into a larger project

Scenario. The isolated fixture works but a school or home project does not.

Route. Preserve the fixture, then compare project inputs and dependencies one at a time. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The first dependency that changes the result becomes the next diagnostic focus; the verified rule remains the baseline. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 6: Write a regression check

Scenario. The behaviour must remain understood after an update.

Route. Save the smallest positive case, the near miss and version metadata. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. A useful check reports a meaningful changed observation and points back to the governing rule. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 7: Explain a limitation honestly

Scenario. The selected feature does not cover an important job or is not universally available.

Route. Name the limitation, show what evidence the feature provides and identify the safer route. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. Good advice is bounded; it neither discards a useful tool nor stretches it into a guarantee. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 8: Choose the right tool

Scenario. Several related methods or commands appear to solve the same task.

Route. Define desired output, evaluation timing, compatibility and acceptable failure modes. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. Select the contract that matches the job and state why at least one tempting alternative was rejected. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Frequently asked questions

Is JavaScript URLPattern mainly a syntax topic?

No. Syntax is the handle. Mastery means stating the contract, predicting a boundary case, collecting the right evidence and choosing a different tool when the contract does not fit.

How long should one practice session be?

Ten to twenty focused minutes is enough for one rule, one worked example, one near miss and one explanation. Stop when the learner can explain the contrast, then preserve the fixture for later retrieval.

Should every edge case be memorised?

No. Memorise the central rule and organise edge cases by cause: version, platform, input shape, browser support or repository state. Keep the primary source beside the fixture.

What can a non-specialist parent ask?

Ask for a prediction, the rule behind it, the observation that could disprove it and one changed case. Those questions reveal understanding without requiring the parent to know the final value.

When is copying an example useful?

Copying establishes a trusted baseline. It becomes learning after the student predicts the result, reconstructs the example, changes one condition and explains the changed outcome.

How do we separate setup errors from concept errors?

Run a known-good minimal fixture first. If it fails, inspect version, support and transcription. If it passes but a controlled variation is predicted incorrectly, the misconception is conceptual.

Should practice start inside a large project?

Not initially. Begin in a disposable directory, tiny script or isolated page. Transfer the verified rule only after the smallest case is understood.

What belongs in revision notes?

Keep the rule in one sentence, the smallest successful example, a near miss, observed output, environment version and one diagnostic question.

What if two computers disagree?

Treat the difference as evidence. Record versions, exact input and relevant state, then consult the versioned primary source before deciding that either observation is wrong.

When should the learner move on?

Move on when the learner can explain the rule, predict two contrasts, diagnose a deliberately broken case and transfer the idea without step-by-step prompting.

References and verification notes

Primary technical source: WHATWG URL Pattern Standard. The URL Pattern Standard defines the constructor overloads, component-wise matching, base URL processing, test() Boolean result, exec() structured result, named groups, default case sensitivity, ignoreCase and hasRegExpGroups.

The worked examples were checked with Node.js 24.19 with the global URLPattern implementation; the fixture verified pathname matching, named group extraction, relative construction with a base URL, default case sensitivity and ignoreCase. The checks confirm the specific examples in this guide; they do not promise identical behaviour on an older version, a different operating system, a different browser implementation, or a repository with different state. Keep the version and environment with the saved fixture.

Last reviewed: 17 October 2026. This article is educational guidance for families and learners. It does not advertise a physical Punggol outlet or make admissions, affiliation, score or outcome guarantees.