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: 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.