You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 23, 2019. It is now read-only.
You may want to read the ReadMe section on Terminology before reading this Spec.
Architecture
ember g worker <worker-name>
A worker is placed in a pod within /app/workers/. Running the generator produces a Worker and an Interface within the worker pod.
/app/workers/<worker-name>/interface.js
/app/workers/<worker-name>/worker.js
A built WorkerApplication will be placed at assets/workers/<worker-name>.js.
Ideally, a worker should be able to use ES imports to include any dependency it needs, but this is tricky as WebWorker's and their relatives do not have access to DOM. Our build tooling should eventually be setup to allow us to include and configure a simple-dom instance ala fastboot on node. At the beginning, it will be on the end user to ensure that what they import will run in a DOMless environment.
WebWorkers can be created via a blob mechanism or via a script url. Our pipeline intends to produce scripts for use via the url method, which means that the build pipeline must produce a standalone script
for each worker in /app/workers/. Additionally, worker.js and interface.js need to remain as modules for use within the application for situations in which the WebWorker API is not available.
Bundling
To create a WorkerApplication, we bundle together interface.js and worker.js along with their dependencies and ember-skyrocket/worker-application, and place the modules in assets/workers/<worker-name>.js. This file must also be responsible for instantiating the worker via some mechanism like the below.
You may want to read the ReadMe section on Terminology before reading this Spec.
Architecture
ember g worker <worker-name>
A worker is placed in a pod within
/app/workers/
. Running the generator produces aWorker
and anInterface
within the worker pod./app/workers/<worker-name>/interface.js
/app/workers/<worker-name>/worker.js
A built
WorkerApplication
will be placed atassets/workers/<worker-name>.js
.Ideally, a worker should be able to use ES imports to include any dependency it needs, but this is tricky as WebWorker's and their relatives do not have access to DOM. Our build tooling should eventually be setup to allow us to include and configure a
simple-dom
instance alafastboot
onnode
. At the beginning, it will be on the end user to ensure that what they import will run in a DOMless environment.WebWorkers can be created via a blob mechanism or via a script url. Our pipeline intends to produce scripts for use via the url method, which means that the build pipeline must produce a standalone script
for each worker in
/app/workers/
. Additionally,worker.js
andinterface.js
need to remain as modules for use within the application for situations in which the WebWorker API is not available.Bundling
To create a
WorkerApplication
, we bundle togetherinterface.js
andworker.js
along with their dependencies andember-skyrocket/worker-application
, and place the modules inassets/workers/<worker-name>.js
. This file must also be responsible for instantiating the worker via some mechanism like the below.The text was updated successfully, but these errors were encountered: