-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Feature detection of module workers is hard #5325
Comments
Ideally the property would be a getter defined on the Worker interface itself, which would make testing for it even cheaper: const supportsModuleWorker = 'type' in Worker.prototype; This might also be useful for other things aside from checking for support - there might be cases where a Worker is used to load scripts dynamically, and the caller needs to have knowledge of this in order to pass the correct value (a module or classic script URL, perhaps). |
The feature detection snippet you post doesn't seem particularly "hard" to me, and matches how feature detection works for every other option-accepting API in the platform. I think this is not worth the extra work. |
One complaint with feature detection in general is that its costly. Being able to feature detect module support without having to pay the cost to spin up a worker seems beneficial. |
Personally, I wasn‘t aware that this was a pattern at all. I find it quite unpleasant. But that might just be me then :D I would want to +1 @wanderview’s comment (and @developit’s suggestion) that if we can avoid spinning up a worker to detect support, that’d be nice. |
If we add a new value to type, how would you check support without (potentially) spinning up a worker? The suggestions without (It's unfortunate that t sorts after n, otherwise you could throw from the name getter to avoid instantiation.) |
Using Regarding UAs that don't support this feature but still access the getters, that's indeed a big issue, and this case is not isolated... I was told it should be considered a browser bug but maybe it would be good to write some enforcing rules on WebIDL so this doesn't happen? (Not sure what form this could take...) But anyway a final problem with "dictionnary traps" is that we can only test if the properties are accessed, not if the value is supported. If in a few years a new WorkerType is added, we would have no way to distinguish its support from |
@NotWoods did you file a bug on that? |
Currently, the advised way to feature-detect support for
new Worker({type: "module"})
is to create an options object and see if the.type
property gets accessed by the constructor with a getter:That seems fairly convoluted. I propose adding
type
property to module instances:The text was updated successfully, but these errors were encountered: