Add Web Workers API (SharedWorker, WorkerScopes, ServiceWorker) (fixes #186)

[danielwegener]

This PR adds interfaces for the following Web Workers API interfaces (all in the experimental package for now - even they are not really tagged as experimental in MDN):

• NavigatorLanguage (mixed into Navigator)
• WorkerNavigator
• WorkerLocation
• WorkerGlobalScope
• DedicatedWorkerGlobalScope
• SharedWorkerGlobalScope
• ServiceWorkerGlobalScope

The following interfaces for ServiceWorkers are added

• ClientType
• ClientQueryOptions
• Clients

The idea is that a user can create a serviceWorker.js with scala.js (with a wrapper that directly calls the main method) like this (note that the message event comes from ServiceWorker):

@JSExport object SharedServiceWorker { val self = SharedWorkerGlobalScope.self @JSExport def main(): Unit = { self.onconnect = (m:MessageEvent) => { m.ports(0).postMessage(s"hello client! I am ${self.name}") } } }

[danielwegener]

Disclaimer: Untested yet, I am on it

[mseddon]

👍 I'll take a proper look tomorrow. It would be good to pull ServiceWorker and friends into the experimental package in this PR too if you're okay with that, but if not I can address that later.

[danielwegener]

Okay, gonna pick up #180 (comment) and move them to the experimental package. Would you be fine with merging all worker related api into a WebWorkers.scala (like ServiceWorker.scala and my new ChannelMessagingApi.scala - which is misleading anyway)?

[mseddon]

Yes, I think that'll work. From a user perspective that won't have much impact.

[mseddon]

Thanks :)

[danielwegener]

NavigatorID should stay where it is but Navigator.serviceWorker should go into the experimental package.
Thought about creating an

implicit class NavigatorOps(private val navigator:Navigator) extends AnyVal { val serviceWorker: ServiceWorkerContainer = js.native } 

in experimental/package.scala. Thoughts on that?

I'll also keep WebWorkers and ServiceWorker separated (different W3C standards) since WebWorkers should already be pretty stable but ServiceWorker probably still will get some changes.

(There is one weird dependency from WebWorkers to ServiceWorkers left, MDN declares WorkerGlobalScope.caches, but those caches are Part of ServiceWorkers spec. Just made it js.Any in WebWorkers)

[mseddon]

Actually, I'd put it in a subpackage specifically for workers- that way people can import just the features that they want without accidentally pulling in all experimental apis (and getting tripped up believing they're accessing a standard method in an unrelated api).

Rather than deleting the currently exposed types from the dom package object, for now we should probably leave a type declaration forwarding to their new location, but with a @deprecated annotation mentioning they should now be imported from the new location. Unsure how many people are actually using it from the old (incorrect) location, but it's nicer to just follow the deprecation warnings (or choose to ignore them) if you have to upgrade your dependencies on a tight deadline. :)

[danielwegener]

Yeah thats what i thought too - so we'd also need a org.scalajs.dom.raw package-object that has @deprecated type-aliases pointing to the new location in experimental.worker.

[mseddon]

Yep, This is what happens when things go in the wrong place. Sorry about that :/

[danielwegener]

One could argue that the types in the raw-package are non-public anyway and one should only rely on types on org.scalajs.dom ;)

[mseddon]

You could. Unfortunately Intellij sucks classes from their package of definition when using autocomplete/import, so people are probably already doomed :)

(And actually, I think there are some classes that are only exposed in dom.raw).

[mseddon]

Oh, definitely think you should use something like dom.experimental.worker (perhaps you can come up with a better name) to keep experimental features separated.

[danielwegener]

Thats what I ment - if they only existed in dom.raw - they never have been public and we could move them freely - but i know what you mean ;) I'd prefer the original spec name (webworkers, serviceworkers -maybe to longish?) - think it is a good idea anyway to roughly split our packages by w3c api - or feature - just tried to stick with the existing convention.

[mseddon]

I definitely agree with classification by specification. As for 'convention', apart from a few apis, it has generally been "chuck it in dom.raw", something I'm trying to incrementally move us away from :)

I notice actually that Channel Messaging is flagged here as 'very compatible'. But Service Workers are (extremely) experimental. For now we can probably keep them in experimental though.

[danielwegener]

(renamed PR Channel Messaging API to Web Workers API - but that one looks stable too - but not fully supported by IE)

[danielwegener]

Okay - I came up with the following solution:

• WebWorkers (except their SharedWorker part) are stable and available. Hence I'll put them into org.scalajs.dom.webworkers package. We need no raw package, because WebWorker classes are not prefixed.
• SharedWorkers are experimental and moved into org.scalajs.dom.experimental.sharedworkers (I am not quite sure if the contained classes should all be within one file)
• ServiceWorkers are experimental and moved into org.scalajs.dom.experimental.serviceworkers
  • ServiceWorker specifics are moved from org.scalajs.dom and org.scalajs.dom.raw into this package
• All moved classes have type aliases with deprecation-marker at the place where they were removed

Caveats:

• now we have two Transferrables, one in dom.webworkers and one in dom.experimental.serviceworkers

Sorry for this back and forth noise (and those tons of builds)

[sjrd]

Drop @return. (the same thing happens elsewhere)

[sjrd]

That's all.

[danielwegener]

@sjrd cheers. all done. I am off writing a scalariform config. or trying to push this into the idea formatter. that was a bit cruel :) (no doubt, reviewing for code style must be no fun either)

[mseddon]

stoopid travis lost network, so that test failed. :/

[mseddon]

LGTM

[danielwegener]

@mseddon squashed!

[mseddon]

Thanks! @sjrd okay to merge?

[sjrd]

LGTM