Architecting Angular Applications with Redux, RxJS, and NgRx

Christoffer Noring

• Publisher: Packt Publishing
• Year: 2018
• ISBN:
  9781787121751
• Edition: 1
• Topic: Design
• Subtopic: Web Design

Manage state in Angular to write high performing web apps by combining the power of Flux, RxJS, and NgRxAbout This Book• Learn what makes an excellent Angular application architecture• Use Redux to write performant, consistent Angular applications• Incorporate Reactive Programming principles and RxJS to make it easier to develop, test, and debug your Angular applicationsWho This Book Is ForIf you have been developing Angular applications and want to dive deeper into the Angular architecture with Redux, RxJS, and NgRx to write robust web apps, then this book is for you. What You Will Learn• Understand the one-way data flow and Flux pattern• Work with functional programming and asynchronous data streams• Figure out how RxJS can help us address the flaws in promises• Set up different versions of cascading calls• Explore advanced operators• Get familiar with the Redux pattern and its principles• Test and debug different features of your application• Build your own lightweight app using Flux, Redux, and NgRxIn DetailManaging the state of large-scale web applications is a highly challenging task with the need to align different components, backends, and web workers harmoniously. When it comes to Angular, you can use NgRx, which combines the simplicity of Redux with the reactive programming power of RxJS to build your application architecture, making your code elegant and easy to reason about, debug, and test.In this book, we start by looking at the different ways of architecting Angular applications and some of the patterns that are involved in it. This will be followed by a discussion on one-way data flow, the Flux pattern, and the origin of Redux.The book introduces you to declarative programming or, more precisely, functional programming and talks about its advantages. We then move on to the reactive programming paradigm. Reactive programming is a concept heavily used in Angular and is at the core of NgRx. Later, we look at RxJS, as a library and master it. We thoroughly describe how Redux works and how to implement it from scratch. The two last chapters of the book cover everything NgRx has to offer in terms of core functionality and supporting libraries, including how to build a micro implementation of NgRx.This book will empower you to not only use Redux and NgRx to the fullest, but also feel confident in building your own version, should you need it.Style and approachThis book covers everything there is to know to get well-acquainted with Angular without bogging you down. Everything is neatly laid out under clear headings for quick consultation, giving you the information required to understand a concept immediately.

1.21 Gigawatt – Flux Pattern Explained

Let's first off explain our title. What do we mean by 1.21 Gigawatt? I'm going to quote the character Doc Brown from the movie Back to the Future (http://www.imdb.com/name/nm0000502/?ref_=tt_trv_qu):

"Marty, I'm sorry, but the only power source capable of generating 1.21 gigawatts of electricity is a bolt of lightning."

Why are we talking about the movie Back to the Future? This is where the name Flux comes from. It's time for another quote from the same movie:

"Yes! Of course! November 5, 1955! That was the day I invented time-travel. I remember it vividly. I was standing on the edge of my toilet hanging a clock, the porcelain was wet, I slipped, hit my head on the sink, and when I came to I had a revelation! A vision! A picture in my head! A picture of this! This is what makes time travel possible: the flux capacitor!"

So as you can see, there is an explanation for the name Flux. It obviously allows us to travel in time. At least for Redux, which we will write about later in this book, time travel is possible through something called time-travel debugging. Whether that needs a bolt of lightning is for you to find out dear reader.

Flux is an architectural pattern created by Facebook. It came about as it was perceived that the MVC pattern simply did not scale. It did not scale for large code bases as they tended to become fragile, generally complicated as more and more features were added, and most of all, unpredictable. Now let's hang on that word for a second, unpredictable.

Large systems were thought to become unpredictable due to their bidrectional data flow between models and views when the number of models and views really grew, as depicted in the following diagram:

Here, we can see that the number of models and views is starting to grow. Everything is somewhat under control as long as one model talks to one view and vice versa. This is, however, seldom the case. In the preceding diagram, we see that suddenly a view can talk to more than one model and vice versa, which means we have a cascading effect on the system and we suddenly lose control. Sure, it doesn't look so bad with just one deviating arrow, but imagine that this one is suddenly ten arrows, then we have a real problem on our hands.

It is the very fact that we allow bidrectional data flows to happen that things get complicated and we lose predictability. The medicine or cure for that is thought to be a simpler type of data flow, a unidirectional flow. Now, there are some key players involved in enabling undirectional data flow, which brings us to what this chapter is meant to teach us.

In this chapter, we will learn:

• What an action and an action creator are
• How the dispatcher plays a central role in your application as a hub for messages
• State management with a store
• How to put our knowledge of Flux into practice by coding up a Flux application flow

Core concepts overview

At the core of the Flux pattern is a unidirectional data flow. It uses some core concepts to achieve this flow. The main idea is when an event is created on a UI, through the interaction of a user, an action is created. This action consists of an intent and a payload. The intent is what your are trying to achieve. Think of the intent as a verb. Add an item, remove an item, and so on. The payload is the data change that needs to happen to achieve our intent. If we are trying to add an item, then the payload is the newly created item. The action is then propagated in the flow with the help of a dispatcher. The action and its data eventually end up in a store.

The concepts that make up the Flux pattern are:

• Action and action creators, where we set up an intention and a payload of data
• The dispatcher, our spider in the web that is able to send messages left and right
• The store, our central place for state and state management

All these together form the Flux pattern and promote unidirectional data flow. Consider the following diagram:

What is depicted here is a undirectional data flow. The data flows from View to Action, from Action to Dispatcher, from Dispatcher to Store. There are two possible ways that the flow is triggered:

• The application is loaded a first time, in which the data is pulled from the Store to populate the view.
• A user interaction happens in the view that leads to an intent to change something. The intent is encapsulated in an Action, and thereafter sent...

Table of contents

• Title Page
• Copyright and Credits
• Packt Upsell
• Foreword
• Contributors
• Preface
• Quick Look Back at Data Services for Simple Apps
• 1.21 Gigawatt – Flux Pattern Explained
• Asynchronous Programming
• Functional Reactive Programming
• RxJS Basics
• Manipulating Streams and Their Values
• RxJS Advanced
• Redux
• NgRx – Reduxing that Angular App
• NgRx – In Depth
• Other Books You May Enjoy