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.
|
||||
* 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
|
||||
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`
|
||||
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
|
||||
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.
|
||||
|
@ -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
|
||||
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`,
|
||||
`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.
|
||||
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
|
||||
`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.
|
||||
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).
|
||||
|
@ -298,7 +298,7 @@ change detection. Generally, you want your channels to run inside the zone unles
|
|||
they need to run outside the zone.
|
||||
|
||||
### 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
|
||||
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:
|
||||
In TypeScript:
|
||||
```TypeScript
|
||||
|
@ -390,8 +390,11 @@ because `bootstrapWebWorker` assumes you're using the default angular MessageBus
|
|||
## MessageBroker
|
||||
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.
|
||||
There are two types of MessageBrokers. The `ServiceMessageBroker` is used by the side that actually performs
|
||||
an operation and may return a result. Conversely, the `ClientMessageBroker` is used by the side that requests that
|
||||
There are two types of MessageBrokers:
|
||||
|
||||
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.
|
||||
|
||||
### Using the MessageBroker In Your Application
|
||||
|
|
Loading…
Reference in New Issue