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
Copy file name to clipboardExpand all lines: public/docs/ts/latest/guide/component-communication.jade
+42-4Lines changed: 42 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -161,7 +161,13 @@ figure.image-display
161
161
162
162
figure.image-display
163
163
img(src="/resources/images/devguide/component-communication/prototype-ui.png"alt="Parent and its children")
164
-
164
+
165
+
.alert.is-helpful
166
+
:marked
167
+
In the subsequent sections of this chapter, we are going to extend and, sometimes, refactor this application. The app we create implements the basic
168
+
workflow, but does not add every nitty-gritty details that we would add to a real application, as those subtleties would distract the focus from the
169
+
most essential things. For example, we do not check inputs thoroughly, and do not spend too much time to create fancy UI.
170
+
165
171
:marked
166
172
## #2: Inviting heroes — parent to child communication with data binding
167
173
@@ -489,7 +495,7 @@ figure.image-display
489
495
Our application will work properly only if we use a singleton instance of `JobService`: the single `HeroJobBoard` instance and all `InvitedHero` instances
490
496
_must use_ the very same `JobService` instance. We'll ensure this behavior by configuring `HeroJobBoard`'s `providers` annotation property this way:
Thanks to the great design of Angular's hierarchical dependency injection system —
@@ -501,10 +507,42 @@ figure.image-display
501
507
502
508
## #7: Assigning the job to a hero — extending the intermediary service
503
509
510
+
Now, we have the `JobService` component, which — according to our intention — encapsulates the business logic of the app. Naturally, we want this
511
+
very component to implement the method of assigning the job to a hero. We need to provide a method for `HeroJobBoard` to assign the job to one of the responding
512
+
heroes, and add an event `InviteddHero` instances listen to in order to get notified about job assignment.
504
513
505
-
_Content_
514
+
This extension is strightforward, as the new, highlighted members of `JobService` show:
To integrate the new `assign()` method with `HeroJobBoard`, we need to change the component template and add a couple of methods to the class body, as shown in
Now, the component template removes the list of responding heroes as soon as the job as assigned to one of them, and the winner is displayed in the Hero Job Board.
526
+
We need to change `InvitedHero`, too, so that it could listen to assignment announcements, and change its UI accordingly:
Here, `InviteHero` subscribes to the `jobAssignedEvent`, and sets the winner hero according to the event parameter (`JobService` defines `jobAssigned` as a
532
+
type of `EventEmitter<Hero>`). The `finalState()` helper method is used to set the right label in the UI of the component that displays
533
+
whether the hero won or lost — provided it undertake the job at all.
534
+
535
+
When the person in need assigns a job to a hero, the UI is immediately updated. This figure shows that Mr. Nice, Bombasto and RubberMan undertook the job,
536
+
and finally it was assigned to Bombasto:
537
+
538
+
figure.image-display
539
+
img(src="/resources/images/devguide/component-communication/assign-job-ui.png"alt="Assign a job to a hero")
540
+
541
+
:marked
542
+
Now, we implemented the basic workflow. We could have been satisfied with the component communication scenarios we've implemented by now, but there's still a
543
+
few things that we should discuss.
506
544
507
-
## #8: A mailcious hero steals the job — issues with multiple facades
545
+
## #8: A malicious hero steals the job — issues with multiple facades
0 commit comments