Pomodoro Clock audio problem

I’m working on the pomodoro clock project functionality before I handle the CSS and I have one test that just will not pass. I have an audio file in the project that should play but instead it throws an error saying Uncaught (in promise) DOMException. I understand this is happening because of Chrome autoplay police but the audio will also not play in either Chrome or Firefox. Can anyone help?

Here is the link: https://codepen.io/sam_donaldson2018/pen/bZmvvP

You are close, I noticed that you were trying to access your audio file with native javascript, getElementById and then probably with event listeners , however you don’t need to, because this is one of the use cases of using react’s ref, here is how you do it

first add the ref attribute to your audio element
<audio ref={this.audio} id="beep" src={BEEP}/>

Next bind the audio element to the this of your class in the constructor of the component using React.createRef()

this.audio = React.createRef()

You now have access to your audio component anywhere in the class, however, you can only access it’s attributes by using the current property,
so for example, this.audio.current.play() would play the audio

One last thing, maybe your audio src play time is too long (I’m not sure) but it wouldn’t work with your source for me, I used my own source, https://s3-us-west-2.amazonaws.com/s.cdpn.io/3/success.mp3 and was able to pass all the tests.

You also have to rewind the audio to pass the final test but I’ll let you figure that out.

2 Likes

Thanks for the help. I didn’t know about refs but the reason why it actually wasn’t working though was I had used the wrong sort of Google Drive link. Thanks to your comment on the link I realised what was wrong, changed it and now it works.

I am curious though after reading your comments and the React documentation on refs why I would use them over the strategy I was using. Are refs inherently better than native JavaScript?

good question. In reality, both ways would be imperatively interacting with the real DOM and not the virtual DOM, the latter being the declarative ‘reactive’ way of doing things considering the one way data flow that react espouses, but still if you must go the imperative route, using refs is more inline with react than getting the DOM node with an id, this below seems a decent answer:

1 Like

Thanks for the link. I’ll have a read and then see about changing my approach.

I have found though that using either approach does not solve the Uncaught (in promise) DOMException error, which still occurs even though all tests now pass.

yeah it does for me too, the reason is audio.play() returns a promise and it’s rejection (for what ever reason) needs to be caught

The problem seems to be that Google requires user interaction for audio to be played and because the tests do not have any the error is thrown. i have changed my code so that the promise is caught but nothing happens because otherwise it would throw the test suite off. It does not occur on Edge or Firefox so I am going to just leave it there.

A year on, this thread really helped unstuck me with the same thing. Many thanks!