Angular 2 – Communication Between Components & Components Design

In the last article, I added the ability to play a media in Echoes Player. I introduced a new reducer which holds the state of the player. In this post I want to share my views regarding communication between different components - and how using the "ngrx/store" as a state management promotes reuse of logics, less code to write and more separation in designing components.

Components Design Decisions

UPDATED: RC.6, 9/2/2016

Echoes Player is an open source media player (no ads included :-)) that plays videos from youtube using its data api and the youtube iframe api. So, after adding the feature to play a video, the next feature in my list is to manage a playlist so I can play several videos in a sequence.

The orange area in the below screenshot is the now-playlist feature:

Screen Shot 2016-03-06 at 5.59.50 PM

Since I have taken few steps to migrate Echoes Player version that I wrote with angular 1 to angular 2, the components design was pretty solid for the this version with angular 2. Also, the code migration for these components was quite solid.

I divided this area into 2 components:

  1. Now Playlist Filter (orange) - this component allows to filter the playlist, clear the playlist and invoke a save playlist action.
  2. Now Playlist (Blue) - this component job is to display the current playlist, mark the current played video, remove videos from playlists and sort videos in this playlist (not implemented for now).

Separating this area into 2 components, keeps the separation of concerns, makes the component smaller and easy to maintain and creates a somewhat better semantics.

Screen Shot 2016-03-06 at 5.51.52 PM

The Development Process for NowPlaylist Angular 2 Component

Creating A The Reducer For Now Playlist State

Since i'm using ngrx/store as a state management (I recommend to read on integrating ngrx/store with angular 2 - part1, part2), I started by defining the state structure that the now-playlist (including its filter). The "initial state" is the actual structure of the now playlist.

I defined the relevant actions that can change this state. Each action returns a new state object by creating a new empty state and merging it with the current state while eventually, appending the new and relevant properties changes of this state. This pattern follows Redux's concepts which I recommend to read and get familiar with.

Since I like writing tests, this store also includes a spec which indicates what operations can be done and the expectations from these actions in the context of the Echoes Player application.

In order to operate on this store and to have one place where these actions are invoked, I chose to create a now-playlist service which both components will use. This approach in the Redux terminology is also known as action creator. This allows us to invoke these actions from one file only and we can test this service easily enough:

The "now playlist" store is passed to both components. Each component will operate on this playlist and will emit actions to change the state through the now playlist service.

To create the whole now playlist feature, the components are constructed in this manner:

Design Of "Now Playlist Filter" Component

The "now playlist filter" component is almost a self contained component - it gets the "nowPlaylist" store as an input parameter only. Inside, It operates on this playlist via the now playlist service - this is how it changes the now playlist store only:

In contrary to using this component's template with "ng-show" with angular 1, I chose to use "*ngIf" in order to toggle the icons on the search field. I like the new syntax - during development it really pops out to the eye and is easy to locate.

As I've written before on 3 more steps for preparing angular 1 code to angular2, migrating the search input from "ng-model" and "ng-change" in angular1 to "[ngModel]" and "input()" in angular2 was pretty straight forward. The new addition in this code is how the "input()" event passes the value to the handler on the component.

I defined a local variable using the "#" syntax - this creates a local template reference to the input dom element - so that it can be used anywhere else in this template. So, I can just reference its value with "searchFilter.value". This allows me to define the function handler on the component without referencing any specific DOM api (platform) - thus - having a simpler function handler - it gets a primitive value and operates on it.

This is the template (I removed a button which is related to saving this playlist since its implemented yet):

Design Of The "Now Playlist" Component

This component is almost similar to the now playlist filter component. The operations of changing the state are self contained within the now-playlist service.

Apart from communicating with the now-playlist service, this component throws 2 events:

  1. select - notifies that a video has been selected in the playlist.
  2. sort - the user sorted the playlist (not implemented).

Eventually, the "select" event, allows me to instruct the player to play a video and keep this logic outside of this component.

This time, I used the "*ngFor" again for rendering the playlist tracks. In contrary to the last I used this directive, this component needs to render the index number of each video in the last and apply filtering value which comes form the previous component.

In order to migrate the "$index" local variable form angular 1, I used the convention of creating a local variable with the "#" sign.

For filtering the "*ngFor" repeater, similar to angular 1, we can use pipe. However, In contrary to angular 1, angular 2 does not include a filter/search pipe for performance reasons - as explained in the docs:

There is no comparable pipe in Angular 2 for performance reasons. Filtering should be coded in the component. Consider building a custom pipe if the same filtering code will be reused in several templates.

However, we can easily create a filer/search pipe. I decided to create such filter since there are more components in Echoes Player that will need this feature (I intend to write a post about it soon).

Here's the full template for this component:

Communication Between Components Explained

Since both components operate on the same "nowPlaylist" store, by nature of angular 2's change detection mechanism, as soon as this store is changed, both components will update its views and will reflect the current state of this store.

So eventually, these components are completely strange to each other, have on knowledge on each other, and still communicating via the now-playlist service, which eventually, communicates the new action to change the state of the store.

In the same way, other components in the app will be able to update the state of the now-playlist store, and like that, communicating between each other.

In my opinion, there is no actual communication between the components, but rather requesting a change in state in form a single source of truth. The design of this flow is driven by data and is changed by events.

Final Thoughts

I chose to experiment with a slightly different design of the now-playlist feature from the angular 1 version. Another approach is to include the the now-playlist-filter component inside the now-playlist component while still incapsulating the code of the filter in a dedicated component - I plan to experiment with this implementation as well.

Communication and state sharing between components is achieved easily via using ngrx/store or a central state management solution. Also, keeping the components as stateless as possible, promotes the idea of writing logics and keeping the actual state outside of the components and creating one source of truth.

As always, the source code for this post is available on github.