parent
cd219b92a2
commit
689ded5c47
|
@ -75,9 +75,9 @@ run specifically on the UI or Worker. Additionally, they contain the core messag
|
||||||
communicate between the Worker and the UI. This messaging code is not in the standard angular2.js file.
|
communicate between the Worker and the UI. This messaging code is not in the standard angular2.js file.
|
||||||
* We pass `loader.js` to bootstrap and not `app.ts`. You can think of `loader.js` as the `index.html` of the
|
* We pass `loader.js` to bootstrap and not `app.ts`. You can think of `loader.js` as the `index.html` of the
|
||||||
Worker. Since WebWorkers share no memory with the UI we need to reload the angular2 dependencies before
|
Worker. Since WebWorkers share no memory with the UI we need to reload the angular2 dependencies before
|
||||||
bootstrapping our application. We do this with importScripts. Additionally, we need to do this in a different
|
bootstrapping our application. We do this with `importScripts`. Additionally, we need to do this in a different
|
||||||
file than `app.ts` because our module loader (System.js in this example) has not been loaded yet, and `app.ts`
|
file than `app.ts` because our module loader (System.js in this example) has not been loaded yet, and `app.ts`
|
||||||
will be compiled with a System.define call at the top.
|
will be compiled with a `System.define` call at the top.
|
||||||
* The HelloWorld Component looks exactly like a normal Angular2 HelloWorld Component! The goal of WebWorker
|
* The HelloWorld Component looks exactly like a normal Angular2 HelloWorld Component! The goal of WebWorker
|
||||||
support was to allow as much of Angular to live in the worker as possible.
|
support was to allow as much of Angular to live in the worker as possible.
|
||||||
As such, *most* angular2 components can be bootstrapped in a WebWorker with minimal to no changes required.
|
As such, *most* angular2 components can be bootstrapped in a WebWorker with minimal to no changes required.
|
||||||
|
@ -143,7 +143,7 @@ The main exception is that there is **no** DOM access from a WebWorker component
|
||||||
import anything from `dart:html` and in JavaScript it means you can't use `document` or `window`. Instead you
|
import anything from `dart:html` and in JavaScript it means you can't use `document` or `window`. Instead you
|
||||||
should use data bindings and if needed you can inject the `Renderer` along with your component's `ElementRef`
|
should use data bindings and if needed you can inject the `Renderer` along with your component's `ElementRef`
|
||||||
directly into your component and use methods such as `setElementProperty`, `setElementAttribute`,
|
directly into your component and use methods such as `setElementProperty`, `setElementAttribute`,
|
||||||
`setElementClass`, `setElementStyle`, `invokeElementMethod`, and `setText`. Not that you **cannot** call
|
`setElementClass`, `setElementStyle`, `invokeElementMethod`, and `setText`. Note that you **cannot** call
|
||||||
`getNativeElementSync`. Doing so will always return `null` when running in a WebWorker.
|
`getNativeElementSync`. Doing so will always return `null` when running in a WebWorker.
|
||||||
If you need DOM access see [Running Code on the UI](#running-code-on-the-ui).
|
If you need DOM access see [Running Code on the UI](#running-code-on-the-ui).
|
||||||
|
|
||||||
|
@ -277,7 +277,7 @@ class MyComponent {
|
||||||
The only substantial difference between these APIs in Dart and TypeScript is the different APIs for the
|
The only substantial difference between these APIs in Dart and TypeScript is the different APIs for the
|
||||||
`EventEmitter`.
|
`EventEmitter`.
|
||||||
|
|
||||||
**Note** Because the messages passed through the MessageBus cross a WebWorker boundary, they must be serializable.
|
**Note:** Because the messages passed through the MessageBus cross a WebWorker boundary, they must be serializable.
|
||||||
If you use the MessageBus directly, you are responsible for serializing your messages.
|
If you use the MessageBus directly, you are responsible for serializing your messages.
|
||||||
In JavaScript / TypeScript this means they must be serializable via JavaScript's
|
In JavaScript / TypeScript this means they must be serializable via JavaScript's
|
||||||
[structured cloning algorithim](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm).
|
[structured cloning algorithim](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm).
|
||||||
|
@ -298,7 +298,7 @@ change detection. Generally, you want your channels to run inside the zone unles
|
||||||
they need to run outside the zone.
|
they need to run outside the zone.
|
||||||
|
|
||||||
### Implementing and Using a Custom MessageBus
|
### Implementing and Using a Custom MessageBus
|
||||||
**Note** Implementing and using a Custom MesageBus is experimental and requires importing from private APIs.
|
**Note:** Implementing and using a Custom MessageBus is experimental and requires importing from private APIs.
|
||||||
|
|
||||||
If you want to drive your application from something other than a WebWorker you can implement a custom message
|
If you want to drive your application from something other than a WebWorker you can implement a custom message
|
||||||
bus. Implementing a custom message bus just means creating a class that fulfills the API specified by the
|
bus. Implementing a custom message bus just means creating a class that fulfills the API specified by the
|
||||||
|
@ -338,7 +338,7 @@ class JsonMessageBusSource extends GenericMessageBuSource {
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Once you've implemented your custom MessageBus in either TypeScript or Dart you can tell angular to use it like
|
Once you've implemented your custom MessageBus in either TypeScript or Dart, you can tell angular to use it like
|
||||||
so:
|
so:
|
||||||
In TypeScript:
|
In TypeScript:
|
||||||
```TypeScript
|
```TypeScript
|
||||||
|
@ -390,8 +390,11 @@ because `bootstrapWebWorker` assumes you're using the default angular MessageBus
|
||||||
## MessageBroker
|
## MessageBroker
|
||||||
The MessageBroker is a higher level messaging abstraction that sits on top of the MessageBus. It is used when you
|
The MessageBroker is a higher level messaging abstraction that sits on top of the MessageBus. It is used when you
|
||||||
want to execute code on the other side of a runtime boundary and may want to receive the result.
|
want to execute code on the other side of a runtime boundary and may want to receive the result.
|
||||||
There are two types of MessageBrokers. The `ServiceMessageBroker` is used by the side that actually performs
|
There are two types of MessageBrokers:
|
||||||
an operation and may return a result. Conversely, the `ClientMessageBroker` is used by the side that requests that
|
|
||||||
|
1. The `ServiceMessageBroker` is used by the side that actually performs
|
||||||
|
an operation and may return a result;
|
||||||
|
2. The `ClientMessageBroker` is used by the side that requests that
|
||||||
an operation be performed and may want to receive the result.
|
an operation be performed and may want to receive the result.
|
||||||
|
|
||||||
### Using the MessageBroker In Your Application
|
### Using the MessageBroker In Your Application
|
||||||
|
|
Loading…
Reference in New Issue