Cape Town | 2026-ITP-Jan | Isaac Abodunrin | Sprint 3 | Grouping data: Alarm Clock

[bytesandroses]

Self checklist

• I have titled my PR with Region | Cohort | FirstName LastName | Sprint | Assignment Title
• My changes meet the requirements of the task
• I have tested my changes
• My changes follow the style guide

Changelist

Implemented alarm clock functionality and countdown timer logic to

• set alarm
• format time correctly
• display the remaining time as it counts down

[cjyuan]

Using user input without proper validation and sanitisation can be dangeours.

Currently, some unusual input values can make your app behave abnormally. Can you add code to sanitise them?

[bytesandroses]

You're absolutely right -- the timer behaves oddly if certain inputs are automatically allowed without sanitizing. If a user enters a negative number, a negative timer is displayed which can't be counted down. And if a number isn't entered, it simply displays NaNs.

To fix this, I've added two validation checks:

1. Ensure the input is a number
2. Ensure the number is positive

[cjyuan]

The countdown interval is not the only state to be reset.

Hint: a user may not click the "Stop" button first before starting a new count down.

You can also consider introducing a dedicated reset function to return the app to a clean initial state to help ensure consistency.

[bytesandroses]

I see what you mean. The clearInterval(timerInterval) only stops the timer counting down -- it doesn't remove it. So it creates a situation where multiple timers can run at the same time.

I've taken your suggestion and handled it in s single reset() function.

[cjyuan]

I meant to point out "alarm not reset", which you have handled now in the reset() function.

In JS, calling clearInterval(timerInterval) is enough to remove the active interval.
Performing timerInterval = null; is optional but a good practice.

[cjyuan]

When the countdown reaches 00:00, there is a one second delay before the alarm sound is played. Is this by design?

At line 25, when timeRemaining changes from 1 to 0, the app only changes the display to 00:00. It's only in the next interval, the code on lines 17-22 is executed.

[bytesandroses]

No this definitely a bug -- it wasn't by design.

I've applied a fix by changing the order of execution: timeRemaining is first decremented so that the alarm sound can be played at exactly 00:00 without needing to start a new loop.

[cjyuan]

When input is 0, there is a delay of one second before the alarm is sounded, and the timer display will mess up.

Note: In setAlarm()

   // This only setups decreaseAlarmTime() to be called one second later (and every second thereafter)
   timerInterval = setInterval(decreaseAlarmTime, 1000);  

  displayAlarm(timeRemaining);  // This line is executed first before decreaseAlarmTim() is called

[bytesandroses]

When input is 0, there is a delay of one second before the alarm is sounded, and the timer display will mess up.

Note: In setAlarm()

   // This only setups decreaseAlarmTime() to be called one second later (and every second thereafter)
   timerInterval = setInterval(decreaseAlarmTime, 1000);  

  displayAlarm(timeRemaining);  // This line is executed first before decreaseAlarmTim() is called

Thank CJ, you're absolutely correct. There's a bug when a user enters a value of 0.

To fix it, I've added an extra step in playAlarm() to check whether the user has inputted a value of 0. If it's 0, then the alarm sound is automatically played without the 1 second delay. Otherwise the countdown is run as usual.

[cjyuan]

Changes look good.