mock API so that user is eligible in a few seconds

these gates before changing state are to handle handleCountdownExpiration being called multiple times

This can happen as react state setting is async, and, until countdownInterval is cleared, we will still be calling getParsedTimeRemaining from the interval.

We don't want to unnecessarily change the state....but the real reason this was added is bc the tests throw a "too many rerenders" error if it isn't here. This is (probably) caused by jest fake timers and some unrelated issue, but it is also good to not change state unnecessarily.

indeed.

Yes. We would still need to apply it conditionally, though, as we only need padStart for the < 10 case.

In this case, I think 0${hours} is more readable...but yeah, subjective. TIL, will keep padStart in mind for future problems.

the tests are designed around the expected behavior of the app. Yes, the implementation here was lazy. And yes, the tests do not approach the granularity of "confirm all numbers are converted to string at the same time before being rendered."

I don't think it's a major systemic issue here though. In this case, confirming the user sees what is expected is the important thing. The actual math and logic for eligibility is handled by the server, where tests are more appropriate to this requirement.

yup I misread the padStart docs. updated + implemented.

Yes, it does seem to be overkill. I added it because the integration test failed without it ("too many re-renders")

The "too many rerenders" is likely due to using fake timers in the test. But there is still the issue of state setting being async -- so we could reasonably expect handleCountdownExpiration to be called more than once in prod before the interval is really cleared.

It's not a big deal if we setIsEligible(true) a few times (would expect once or twice tops in prod). But since this was needed to clear the test, and does avoid an unnecessary state change, went ahead and put it in.