Use const instead of let to help signify that the initialized values are not expected to change. This commit resolves some review requests on APlayer PR #175.
It appears that the "pause" event is never triggered if you call `audio.pause()` on a playing audio element and then immediately set `audio.src`. The "abort" event, however, _is_ called in this case.
Because the "pause" event isn't raised, the APlayer code that resets the pause button state doesn't trigger. This leaves the APlayer in a state where the pause button is still showing but the audio element _isn't_ actually playing. Because `APlayer.toggle()` (which is called by the Play/Pause button) does not check the state of the audio element, and instead checks the state of the UI, we end up in a situation where the pause button is visible but we're not playing. The call to Toggle, then, calls `APlayer.pause()` which checks to see if it's already paused or not. Because the audio element is already paused, the call is ignored and the event never triggers (which would reset the button UI).
This [temporary] "fix" resolves the issue by intercepting the "abort" event that is triggered when the "pause" event is aborted. It then runs the same logic as the "pause" event, checking to see if the playback button is in a "paused" state and, if so, resetting it to a "play" button state.
_In theory_, the checks at the beginning of the `pauseHandler` arrow function should be enough to safeguard any other unrelated calls to "abort".
In the default state, each audio element should already have the music url set. However, if a user externally adjusts the music stored on the APlayer and attempts to switch to it, everything _but_ the audio would change. This allows users to modify the music set in the options manually.
This change appears to have been made to support playlist auto-advance in mobile. This was a workaround to handle the autoplay guard lower in the function which was removed in an earlier commit on this branch. The play call is now handled external to the `setMusic` call, which allows external logic to determine whether play should be called on mobile or not.
When playlists advance, the music should continue to play. The recent change to stop `setMusic` from "autoplaying" in this case must now be handled directly by the caller. This is far more clear to read: "set next music and play it."
The `autoplay` option only makes sense in the constructor. After that, callers of `setMusic` should determine whether or not to begin playback based on their own state.
DIYgod
DIYgod
Michael
Eric Robinson
gkiwi
Karl Chen
liwanglin12