Change:
in step 43 of the js beta music player project, we are asked to: add an if to check if userData?.currentSong is falsey. But if you type an if like below, it is accepted even though that's not a falsey check? I also looked at the code in step 44 and the condition doesn't seem to be a general falsey check there either, so maybe this step 43's instructions should be updated to say "add an if to check if userData?.currentSong is null"? a rewrite of the instructions is needed to be clearer about not requiring a falsey check but just a check against null. No response N/A No response
iirc the tests were updated to be more accepting of conditions that would still work for the project but weren't what the user stories ask
Hmm. I am not sure this issue fits the behaviour? It is really the description that is too restrictive in this case and doesn’t match the test?
There was change from requiring to falsey Further steps still have in the seed code.
It looks like when someone tried to fix the tests to allow the falsey answer they also changed the description in reverse to make it more restrictive than it was? (That is, a falsey condition requires that many conditions like false “” null and undefined are checked, but a null check is much simpler?)
Allowing any falsy value, through type coercion, implicitly allows all falsy values. However, we are not expecting the value to be an empty string or , so allowing explicit falsy value checks that isn't wouldn't be correct. is the explicit falsy value used by the code to denote "not set" or "unset", so allowing an explicit check for that value is fine. But I don't think the test should allow for an explicit value check. I don't believe there is a code path where the property being means the same as it being . If it is , I would assume something went wrong. Not that I thoroughly looked at the code. So if anything, we should update the test to not allow an explicit check but keep the check. Edit: Just to be super clear. I understand allowing is implicitly the same as allowing any explicit falsy value check. However, when reading code, explicit value checks signals something to the reader which a implicit check does not. So if I was reviewing the code, I would ask for an implicit falsy or an explicit check.
My confusion remains with the description. Someone sees this step’s description and posts on the forum with their code only checking for null, my first instinct is to say: hey, the instructions said check for a falsey not check for null. (This actually happened by the way which is why I opened this). Then I found out that actually the test didn’t care that the person wrote code that only checked for null. My point is this; if the test wants a null check then pls make the step ask for a null check and not a falsey check.
I assume we wanted to allow a falsy check instead of only a literal check, and in doing so we also change the written requirements to say a falsy check. I don't have an issue with removing the literal and part of the regex test. But the requirement doesn't state how the falsy check should be preformed, that is, it doesn't say it has to be an implicit coercion. So we might want to allow using as well.
I'm in the opposite camp (lasjorg's original camp?). There are other conditional points in the code flow that use an explicit check, and the property is initialised to in the code. It does not make sense to then allow a falsy condition in the step. We should revert the tests to require an explicit comparison.
I'm inclined to agree, but it is more an opinion. Strictly speaking, is used as an intentional value and other falsy values are not expected. Could you check for a by using implicit coercion? Sure. But in doing so, you are allowing potentially unexpected values to pass the check.
I will give my vote to revert the change back to a strict check. A falsy check seems too broad and allows for unexpected values.
I'm going to open this up for contribution. A PR which resolves this issue will update the instructions and tests for the linked step to require an explicit null check.
/assign
We typically do not assign issues. Instead, we accept the first pull request that comprehensively solves the issue. Issues labeled with or are open for contributions. Please make sure you read . We prioritize contributors following the instructions in our guide. Join us in or if you need help contributing - our community will be happy to assist you.

Discussion:
# --description-- <del> Within the arrow function of the event listener, add an `if` to check if `userData?.currentSong` is `falsey`. </del> <ins> Within the arrow function of the event listener, add an `if` to check if `userData?.currentSong` is `null`. </ins> Inside the `if` block, call the `playSong()` function with the `id` of the first song in the `userData?.songs` array. This will ensure the first song in the playlist is played first. # --hints-- <del> You should create an `if` statement with the condition `!userData?.currentSong`. </del> <ins> You should create an `if` statement with the condition `userData?.currentSong === null`. </ins> ```js <del> assert.match(code, /ifs*((s*!userData?.currentSongs*|s*userData?.currentSongs*===s*nulls*|s*userData?.currentSongs*===s*undefineds*))s*{/) </del> <ins> assert.match(code, /ifs*(s*userData?.currentSongs*===s*nulls*)s*{/); </ins> ``` You should call the `playSong` function with `userData?.songs[0].id` inside your `if` block. ```js <del> assert.match(code, /ifs*((s*!userData?.currentSongs*|s*userData?.currentSongs*===s*nulls*|s*userData?.currentSongs*===s*undefineds*))s*{s*playSong(s*userData?.songss*[s*0s*]s*.ids*)s*;?s*}/) </del> <ins> assert.match(code, /ifs*(s*userData?.currentSongs*===s*nulls*)s*{s*playSong(s*userData?.songss*[s*0s*]s*.ids*)s*;?s*}/); </ins> ``` # --seed--