-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cm/safari audio hack #440
base: main
Are you sure you want to change the base?
cm/safari audio hack #440
Conversation
✅ Deploy Preview for dailp ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left two comments, neither of them are blockers here but both are probably worth a short conversation.
// TODO: is there a place to store this instead of doing this check everytime? | ||
// happens at this level because vite will run this server-side and crash sometimes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My first thoughts are to do this through React state. I figure you considered that already though. Is there anything worse about using state than running this every time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll look for a way to see if we are on the server-side, and short-circuit if we are? I wonder if that would let us make it a constant.
Get around iOS safari never triggering the "oncanplaythrough" event, which our audio player waits for before showing the play button.