LEARN. PRACTICE. GROW.A value has a type; a boundary has a contract
A JavaScript variable may receive values of different types over time. That does not mean every operation behaves identically for those values. A quantity received as text remains text until converted. Before analyzing a total, identify the origin and type of each operand.
This path uses the published ECMAScript 2026 edition. Questions concern standardized features and state when a browser environment is required. Program execution is not needed to answer. TypeScript and UI frameworks belong to their own paths; a feature appearing in the standard does not prove support in every older engine.
Conversion does not validate the field
Consider a file where quantity "6" is followed by increment 2. The expression "6" + 2 produces "62"; the operator chooses concatenation with this string operand. Explicit conversion can fix the addition, but whether the source format is permitted remains a separate question.
Number accepts empty or whitespace-only text as zero. parseInt may accept "28ms" as 28 while ignoring its suffix. Neither result establishes compliance with a digits-only contract. Retain the text until validating the entire format and then enforce the numeric range. A successfully converted value can still be invalid for the application.
Absence, falsity and legitimate zero
On an operations dashboard, zero may mean that a call must not be retried. If the schema already guarantees an integer from 0 to 4 or absence, retryLimit || 2 changes that decision: zero is falsy and activates the fallback. retryLimit ?? 2 preserves zero and uses 2 only for null or undefined.
This operator does not validate numbers or text. If the source still admits "false", that nonempty string is truthy; Boolean does not interpret its linguistic meaning. Define missing values separately from valid domain values. For a textual true/false option, reject other strings and perform explicit mapping after validation.
Equality and bounds that matter to the data
Strict equality does not convert "04" to the number 4. This helps detect representation differences, but does not replace a decision about identity. Two distinct objects with equal properties are not automatically the same entity either. Decide whether you are comparing a reference, a key or normalized content.
For Number, Number.isFinite rejects text and nonfinite values without conversion. Number.isNaN specifically detects NaN. Object.is distinguishes signed zeroes and considers NaN equivalent to NaN. Use these differences when they matter to diagnosis, without turning one equality choice into a universal rule for every domain.
Precision and representation are separate decisions
An identifier such as "9007199254740993" should not pass through Number merely because it contains digits. Outside safe integers, distinct integer values may become indistinguishable. Converting the rounded result back to a string does not recover information. If the key is textual, validating and retaining the text usually matches the contract.
BigInt supports exact integer arithmetic, but its decimal representation also fails to preserve significant leading zeroes. Furthermore, 5n + 2 mixes numeric types and throws TypeError; choosing a numeric domain requires an explicit justification. For Number quantities, Number.isSafeInteger checks integrality and the safety bound, while application-specific limits still need enforcement.
Guided reading of an import boundary
The shown program accepts only nonempty strings of ASCII digits and quantities up to 5000. The first condition rejects other types, empty text and any character outside that set, including a trailing line break. Only then does conversion and quantity validation occur. The function returns a result object; it neither saves data nor changes stock.
By inspection, "0007" is accepted with value 7 and "0" with value 0. "28ms", "1e3" and "" fail format validation. "5001" has an accepted format but fails the range check. A very long digit string may produce an unsafe or infinite Number and is rejected by the second condition. The caller must inspect ok before using value.
Decision and acceptance evidence
When reviewing the importer, separate three questions: does the received form belong to the contract, does conversion preserve the required information, and does the converted value fit the domain? A fix that merely replaces parseInt with Number can still accept whitespace, exponents or other forbidden forms. A truthiness-based fix can remove permitted zero.
To justify the decision, trace valid input, zero, absence, an invalid suffix and an out-of-range quantity through to their results. Explain which condition accepts or rejects each. This lesson’s single- and multiple-choice questions ask you to perform that analysis without installing tools or executing snippets.
function readQuantity(raw) {
if (typeof raw !== "string" || raw.length === 0 || /[^0-9]/.test(raw)) {
return { ok: false, reason: "invalid-format" };
}
const value = Number(raw);
if (!Number.isSafeInteger(value) || value < 0 || value > 5000) {
return { ok: false, reason: "out-of-range" };
}
return { ok: true, value };
}Read the example without running it. The regular expression searches for any character that is not an ASCII digit; it does not validate only a prefix. The result separates acceptance from quantity, so zero does not serve as an error signal.
Common pitfalls
Expecting addition from + with text; using || to preserve zero; accepting parseInt prefixes; treating every Number as a safe integer; converting text identifiers.
Related topics: Bindings, functions and closures · JSON, text and time contracts · Errors, validation and failure contracts
Define the input contract first. Convert only after deciding what information may be lost.
Reference: Grammar and types · ECMAScript 2026 (17th edition); browser APIs identified separately