Code change:
# --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--

Related discussion:
text: 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.