phaser
phaser copied to clipboard
Change the order of types (SoundManager)
Since the default audio context is Web Audio
in Phaser, I believe many developers will predominantly use Web Audio. I encountered an issue while trying to use the decodeAudio()
as described in Phaser.Sound.WebAudioSoundManager
. The tsc throws an error because the type of Phaser.Game.Sound
starts with Phaser.Sound.NoAudioSoundManager
.
Property 'decode' does not exist on type 'NoAudioSoundManager | HTML5AudioSoundManager | WebAudioSoundManager'.
Property 'decode' does not exist on type 'NoAudioSoundManager'.
While I understand that this is not mandatory, I believe it would be more helpful for developers if the order of the types was reversed. 👍
Please consider the following change:
// Current Order
sound: Phaser.Sound.NoAudioSoundManager | Phaser.Sound.HTML5AudioSoundManager | Phaser.Sound.WebAudioSoundManager;
// Proposed Order
sound: Phaser.Sound.WebAudioSoundManager | Phaser.Sound.HTML5AudioSoundManager | Phaser.Sound.NoAudioSoundManager;
This adjustment prioritizes WebAudioSoundManager
while developing, which contains the decodeAudio()
, potentially reducing issues related to the mentioned tsc error or etc.
Thank you!
I think the error is correct because the actual Sound Manager may be Web Audio, HTML5, or No Audio depending on the device.
I think the error is correct because the actual Sound Manager may be Web Audio, HTML5, or No Audio depending on the device.
Actually it is not a real error of tsc during the build. While developing on typescript environment, i think tsc implicitly infer the first index of enumerated strings ( NoAudioSoundManager | HTML5Audio | WebAudio ), so its default SoundManager on the dev environment is NoAudioSoundManager.
So linter or tsc throws an type error if i try to use decodeAudio of WebAudioSoundManager.
I do believe it's not necessary because as you said, SoundManager type will be correctly assigned accoring to their devices after builded.
But it'll be more helpful for developers to change the order while developing with typescript. (Because then tsc implicitly infer the WebAudioSoundManager, which is default context of Phaser, preventing potential issues when they try to use WebAudioSoundManager. )
Here's the situation i mentioned above while developing Phaser with Typescript.
Are you sure that will resolve it? I don't believe tsc uses just the first index of the type to run checks against. It runs it against them all. So having it at the end will still cause the same error because it cannot be sure that this.sound
isn't NoAudioSoundManager
without you casting it as such in your code somewhere.
Are you sure that will resolve it? I don't believe tsc uses just the first index of the type to run checks against. It runs it against them all. So having it at the end will still cause the same error because it cannot be sure that
this.sound
isn'tNoAudioSoundManager
without you casting it as such in your code somewhere.
Ah in this case, i can statically set the type this.sound
as a WebAudioSoundManager
. Thank you for answering