Angular has different mechanisms for sharing data between components. The choice
of the sharing method mostly depends on the relationship of the related
components. Typically, within the context of a parent-child topology, the most
straightforward choice would be to use the @Input and @Output decorators.
For sibling components, relying on a data sharing service seems to be the most
obvious solution. In any case, once you have settled on the choice of a
communication topology, you need to decide which data propagating mechanism to
use.
Generally, components use EventEmmiter objects to share data with each other.
When you pass data into an Angular component with an @Input decorator, you are
actually using an EventEmitter object. Although this solution is appropriate
for the majority of situations, this is not always the case. Let's consider the
following example:
An emitter component fires an event when a certain situation happens using an
EventEmitter object. The event is designed to be received by the two
receivers. These two components are independent from each other and they are
controlled by a router which means that only one of them is executed at once.
However, we want both receivers to be able to process the latest version of the
shared data sent by the emitter component. The problem here is that the emitter
sends its data only once as soon as the trigger event is fired. Only the active
receiver will receive the shared data.
Below is an interactive demo of this example:
A sidebar component (the emitter) contains a drop-down menu with different value choices. When a user selects one or more of these choices, the related values are sent to the currently displayed receiver (receiver 1 at start-up). The displayed receiver is nested inside a router component. Since only one of the components controlled by the router is executed at once, the drop-down menu's values are not propagated when the user decides to display the second receiver by clicking on the second tab. Consequently, the user's input selection is lost, even when going back and forth from receiver 1 to receiver 2.
Angular's sharing mechanisms rely on the ReactiveX library. The
EventEmitter definition extends the ReactiveX library's
Subject class:
class EventEmitter<T> extends Subject {
...
}
As a result, any of the varieties of Subject is suitable to be used
instead of EventEmitter. For the present use case, a ReplaySubject object
with a buffer size of 1 seems to be a good solution to solve the issue
previously described. That way, the latest version of the shared data sent by
the emitter will be sent again each time a new receiver will subscribe to its
data stream:
See the result for yourself:
As you can see, the communication topology is not the only thing to think about when designing the software architecture of your Angular application. Take the time to read about the different Subject classes from the ReactiveX library before implementing your own homemade solution.