Chore Door project

Project link:

After completing step 10, this is the code inside script.js:

const doorImage1 = document.getElementById('door1');
const botDoorPath = '';
door1.onclick = () => {
  doorImage1.src = botDoorPath;

Why does line 4 not throw a ReferenceError? What is door1 referencing?

1 Like

I copied the code into a code editor and i tried it, it says module door1, It looks like it recognizes the id as a module, that’s all I got to know, I’ll look further for it


Did you find anything more about this?

Bumping to top (sorry if this is against the rules)

Bump. Anyone know what’s going on with this? @lolfail

Recently a ticket was created for this lesson and some revision done with the instructions. There was a discussion around using globals in the script, and how it was not a good practice so the lesson should read,

doorImage1, doorImage2, doorImage3

in place of every door(N) except the id, in


Bottom line, do not use door(N) in the code.

@mtf Thanks for getting back to me, I didn’t notice that the instructions have indeed been updated. But I’m still not clear on how door1 could reference doorImage1 without door1 being defined anywhere in the script?

1 Like

The explanation for this came up a few weeks ago, and the conversation led to a ticket being submitted, and the course revised. I’ll have to dig around for that topic.

Briefly, id="door1", causes the browser to create a global variable by that name. What gets assigned I wouldn’t know. I suspect it to be a nodelist, which is why we could access it even without caching the nodes. door1 indeed had a src attribute.

I tracked down the conversation but as it is DM, have asked the other participants if we can make it a public topic. It would end up in the Get Help JavaScript forum. Waiting for their response.

In the meantime, the CXP team accepted the recommendation to correct the course so that we are not misusing globals as they are rather vulnerable to other scripts using the same variable names.

JS occupies a single namespace which means collisions with other script libraries is possible in the global scope. By caching our nodes and not depending upon a global, we protect the objects we’ve cached and are less vulnerable to collisions.

ID is far more focused than we knew, apparently

1 Like

A post was split to a new topic: To make this more efficient