Pass the Salesforce Salesforce Developer JavaScript-Developer-I Questions and answers with CertsForce

Requirement:

The message should be displayed only on the first click of the button.

Original behavior:

The handler listen is attached with button.addEventListener( ' click ' , listen);.

That means listen is called on every click until the listener is removed or configured otherwise.

Two correct ways to ensure the listener only fires once:

Use the once option in addEventListener

Remove the event listener after the first run inside the handler

Option C:

On line 06, add an option called once to button.addEventListener().

This means modifying line 06 to:

button.addEventListener( ' click ' , listen, { once: true });

The once: true option tells the browser:

Call the listen function at most once.

After it is called the first time, automatically remove the listener.

So:

First click: alert shows, listener is removed automatically.

Subsequent clicks: no further calls to listen, no alerts.

This satisfies the requirement.

Option D:

On line 04, use button.removeEventListener( ' click ' , listen);

This means updating the handler:

function listen(event) {

alert( ' Hey! I am John Doe ' );

button.removeEventListener( ' click ' , listen);

}

Now:

On the first click, listen is executed:

It shows the alert.

It removes itself from the button’s click listeners.

On subsequent clicks, listen is no longer registered, so nothing happens.

This also satisfies the requirement.

Why A and B are incorrect:

Option A:

On line 04, use event.stopPropagation();

event.stopPropagation() stops the event from bubbling up the DOM tree.

It does not prevent the current listener from being called again in the future.

The click handler will still run on every click; it just prevents other listeners higher in the DOM from receiving the event.

Option B:

On line 02, use event.first to test if it is the first execution.

There is no built-in event.first property in standard DOM events.

This property does not exist and will be undefined.

You would need your own external flag (let hasRun = false;) to track first execution, but that is not what B describes.

Therefore, the two correct modifications are:

Answer: C, D

Study Guide / Concept References (no links):

addEventListener options object: { once: true }

removeEventListener to manually deregister event handlers

Event propagation (event.stopPropagation) vs handler lifecycle

DOM event model and listener registration

Definitions in testing context (treating “positive” as “test reports a bug/failure”):

True positive : System has a bug; test correctly fails.

False positive : System is correct; test fails (reports a bug that isn’t actually a bug).

True negative : System has a bug; test correctly passes indicating “no success” in detection context (less common phrasing here).

False negative : System has a bug; test incorrectly passes (missed bug).

Here:

The real requirement , as stated, is to verify the existence of the checkout button .

The button still exists ( < button > Checkout < /button > ), so the system behavior is correct regarding that requirement.

The test, however, is checking for an overly specific condition (class= " blue " ), which is not actually part of the stated requirement.

The test fails , saying there is a problem (no button with class= " blue " ), even though from the requirement standpoint, the checkout button is present.

So:

No real bug concerning presence of checkout button.

Test reports a failure → a false positive .

Therefore, the correct category is D, False positive.

We want mechanisms that persist data between page loads (i.e., after refresh or navigation), in the browser.

A. localStorage

Part of the Web Storage API.

Data persists across page reloads and browser restarts (until explicitly cleared).

Scoped per origin (protocol + host + port).

This is a correct persistent storage API.

B. indexedDB

A low-level, client-side NoSQL database in the browser.

Stores large amounts of structured data and persists across reloads and sessions.

This is also a correct persistent API.

C. cookies

Small key/value pairs stored by the browser and often sent with HTTP requests.

Can have expiration dates and persist across page loads and sessions.

They are a traditional persistence mechanism in browsers.

So cookies also qualify.

D. global variables

Global JS variables exist only for the life of the current page context.

When the page is refreshed or navigated away, they are lost.

They do not persist between page loads.

E. IIFEs (Immediately Invoked Function Expressions)

A pattern for creating a new scope, not a persistence mechanism.

Variables inside an IIFE are still lost when the page reloads.

Thus, the three persistent browser APIs are:

localStorage

indexedDB

cookies

New behavior: sum3 now returns the sum of all elements .

Line 01: sum3([1, 2, 3]) → 1 + 2 + 3 = 6

Assertion on line 02: res === 6 → passes.

Line 04: sum3([1, 2, 3, 4]) → 1 + 2 + 3 + 4 = 10

Assertion on line 05: res === 6 → 10 === 6 is false, so the assertion fails.

So:

Line 02 assertion passes → D.

Line 05 assertion fails → C.

document.querySelector( ' #row-as ' ) returns the single element with id row-as.

That element has a classList property with add, remove, etc.

Correct usage:

document.querySelector( ' #row-as ' ).classList.add( ' priority-account ' );

Why others are wrong:

A: querySelectorAll returns a NodeList, not a single element, so it does not have a classList property.

C: DOM elements do not have a classes array or push; they have classList.

D: document.getElementById( ' row-as ' ) is fine to get the element, but there is no addClass method in standard DOM; that’s a jQuery-style API, not vanilla JS.

Person instances have:

firstName and lastName as string properties.

A name method that returns a combined string: `${this.firstName},${this.lastName}`.

Object.assign({}, john) creates a shallow copy of john into a new object, dan.

After:

dan.firstName = ' Dan ' ;

dan.name() returns " Dan,Doe " .

Analysis of options:

A: dan.firstName() and dan.lastName() are function calls , but firstName/lastName are strings, not functions → TypeError.

B: Calls the defined method and uses both names correctly.

C: dan.name is a function reference; you’d still need to call it: dan.name().

D: dan.firstName + dan.lastName is " DanDoe " , no separator. It accesses the properties but not in the method the developer defined.

The intended way, using the provided API, is dan.name().

The function:

async function functionUnderTest(isOK) {

if (isOK) return ' OK ' ;

throw new Error( ' not OK ' );

}

Behavior:

If isOK is true:

The function resolves (fulfills the promise) with value ' OK ' .

If isOK is false:

The function throws, which in an async function becomes a rejected promise with Error( ' not OK ' ).

We want an assertion that accurately tests the successful path for isOK === true.

Key points about console.assert:

Signature: console.assert(condition, message?)

If condition is falsy , it logs message as an assertion failure.

If condition is truthy , nothing is logged.

We also must understand await:

await functionUnderTest(true) will resolve to the string ' OK ' .

Now evaluate options.

Option A:

console.assert(await functionUnderTest(true), ' OK ' );

await functionUnderTest(true) → ' OK ' (truthy).

console.assert( ' OK ' , ' OK ' );

Condition is ' OK ' (truthy), so assertion passes.

The message ' OK ' is only shown if the condition is falsy, which it is not.

This correctly verifies that the promise resolved (i.e., did not reject). Among the given options, this is the only one that both:

Uses await properly on the async function, and

Associates the message with the expected success " OK " .

Option B:

console.assert(await (functionUnderTest(true), ' not OK ' ));

Inside the parentheses, the comma operator (a, b) evaluates a, discards it, and returns b.

So (functionUnderTest(true), ' not OK ' ):

Calls functionUnderTest(true) (returns a promise, but its result is discarded),

The expression evaluates to the string ' not OK ' .

Then await ' not OK ' just resolves to ' not OK ' immediately (not a promise).

console.assert( ' not OK ' );

Condition is ' not OK ' (truthy), so the assertion passes regardless of what functionUnderTest actually does.

This does not meaningfully test the function and is misleading.

Option C:

console.assert(functionUnderTest(true), ' OK ' );

functionUnderTest(true) returns a Promise , not the string ' OK ' directly.

A Promise object is always truthy.

So console.assert(promise, ' OK ' ) will pass, even if the promise later rejects.

Also, there is no await, so we are not actually waiting for the async result.

This is not a correct way to assert on an async function’s resolved value.

Option D:

console.assert(await functionUnderTest(true), ' not OK ' );

await functionUnderTest(true) still resolves to ' OK ' (truthy).

console.assert( ' OK ' , ' not OK ' ); passes.

However, the message ' not OK ' is the opposite of what we expect for the success case and is only used when the condition fails.

This makes the assertion logically inconsistent with the function behavior (it would show " not OK " if the assertion failed).

Therefore, the only assertion that:

Properly waits on the async function, and

Has expectation text that matches the successful behavior ( ' OK ' )

is:

Answer: A

Study Guide / Concept References (no links):

async and await behavior in JavaScript

Promises resolving vs rejecting in async functions

console.assert(condition, message) usage

Truthy and falsy values in JavaScript

Comma operator (a, b) semantics

When pet1 = new Pet(); is created:

Inside Pet constructor:

Animal.call(this, size, type);

this.size = size;

this.name = name;

this.owner = owner;

Animal.call(this, size, type):

Sets this.type = type || ' Animal ' → ' Animal ' (because type is undefined).

Sets this.canTalk = false.

Then this.size, this.name, this.owner are set (to undefined since no args passed), but they do exist as properties .

So as own properties, pet1 has: type, canTalk, size, name, owner.

speak is defined on Animal.prototype, so pet1.speak exists by inheritance, but is not an own data property created in the constructor.

From the listed options, three important properties directly set by constructor logic and clearly used in behavior are:

canTalk

name

type

Thus, C, D, E.

We start with:

let productSKU = ' 8675309 ' ;

The requirement:

Final SKU string:

Length: 19 characters.

Starts with ' sku ' .

Remaining characters are digits padded with zeros on the left (to reach total length).

We can use String.prototype.padStart and String.prototype.padEnd:

str.padStart(targetLength, padString)

If str.length < targetLength, it adds padString to the start until the length is targetLength.

str.padEnd(targetLength, padString)

Similar, but adds padString to the end.

We want a pattern like:

First, pad the numeric part out to a fixed length with zeros.

Then, pad to total length with ' sku ' at the start.

Analyze Option B

productSKU = productSKU.padStart(16, ' 0 ' ).padStart(19, ' sku ' );

Step 1: productSKU.padStart(16, ' 0 ' )

Initial productSKU is ' 8675309 ' (length 7).

After padStart(16, ' 0 ' ), we pad zeros on the left to reach length 16.

We need 16 − 7 = 9 zeros:

Result after step 1:

productSKU === ' 0000000008675309 ' // length 16

Step 2: .padStart(19, ' sku ' )

Now productSKU has length 16.

We call padStart(19, ' sku ' ):

We need 19 − 16 = 3 extra characters.

The pad string ' sku ' is exactly 3 characters, so it is added as-is at the start.

Result after step 2:

productSKU === ' sku0000000008675309 ' // length 19

This satisfies:

Length 19.

Starts with ' sku ' .

Remaining characters are zeros plus the original digits, i.e. a zero-padded numeric section.

While the literal sample sku000000008675309 in the text has a slightly different count of zeros, Option B follows the requirement pattern:

3 characters of ' sku '

Numeric part padded with zeros to make 16 characters total for the numeric part

3 + 16 = 19 total characters

Option B matches the intended logic using padStart and padEnd.

Why the other options are incorrect

Option A:

productSKU = productSKU.padEnd(16, ' 0 ' ).padStart( ' sku ' );

padEnd(16, ' 0 ' ) produces ' 8675309000000000 ' (original number followed by zeros).

padStart( ' sku ' ) is invalid usage:

padStart takes a numeric target length as the first argument, not a string.

Passing ' sku ' as the first argument leads to type coercion that does not achieve the intended behavior.

This will not reliably produce the desired SKU.

Option C:

productSKU = productSKU.padEnd(16, ' 0 ' ).padStart(19, ' sku ' );

First padEnd(16, ' 0 ' ) from ' 8675309 ' gives ' 8675309000000000 ' (length 16, zeros at the end).

Then padStart(19, ' sku ' ) adds 3 chars ' sku ' at the front:

Result: ' sku8675309000000000 ' .

This string starts with ' sku ' , but the zeros are at the end of the digits, not padding the numeric part on the left as desired.

Option D:

productSKU = productSKU.padStart(19, ' 0 ' ).padStart( ' sku ' );

First padStart(19, ' 0 ' ) pads zeros at the left to make the length 19.

Then padStart( ' sku ' ) again incorrectly uses a string where a numeric targetLength is required.

This will not produce the correct SKU format.

Therefore, the only option that correctly uses padStart to create a 16-character zero-padded numeric portion and then a 19-character string starting with ' sku ' is:

Answer: B

References / Study Guide concepts (no links):

String.prototype.padStart(targetLength, padString)

String.prototype.padEnd(targetLength, padString)

String length calculations

Left-padding numeric strings with zeros

Building prefixed identifiers with fixed total length

If the dependency was added as a dev dependency (yarn add --dev), it goes into devDependencies.

When NODE_ENV=production, Yarn (and npm) typically skip devDependencies on install.

Thus the package doesn’t get installed for other team members in a production environment.

YARN_ENV is not a standard variable, --save is npm syntax (and Yarn saves by default), and --add is not how Yarn works (the command itself is yarn add).