Imagine that you’re a proud owner of a convenience store that sells various products. Remember how did you start? You rented an empty place (i.e. the store was in its initial state). Then you purchased shelves and ordered products. After that, multiple vendors started delivering products. You hired employees that arranged these products on the shelves in a certain order changing the state of the store. Then you put out the Grand Opening sign and lots of colorful balloons.

Customers started visiting your store and buy products. When the store is open, some products lay on the shelves, and some products are in the shopping carts of customers. Some customers are waiting in lines at the cash registers, and there are store employees there. In other words, we can say that at any given moment, your store has the current state.

If a customer takes an action, e.g. buys (or returns) five bottles of water, the cashier scans the barcode, and this reduces (or increases) the number of bottles in the inventory, i.e. updates the state. If a vendor delivers new products, your clerk updates the inventory (i.e. state) accordingly.

Your web app can also maintain a store that holds the state of your app. Similarly to a real store, at any given time your app’s store has a current state. Some data collections have specific data retrieved from the server and, possibly modified by the user. Some radio buttons are checked, the user selected some products and navigated to some routes represented by a specific URL.

If the user interacts with the UI, or the server sends new data, these actions should ask the store object to update the state. But to keep track of the state changes, the current state object is never updated, but a new instance of the state object is created.

What’s Redux?

Redux an open-source JavaScript library that takes care of managing application state. Initially, the React.js developers made Redux popular, but since it’s just a library for maintaining an app state, it can be used in any JavaScript app. Redux is based on the following three principles:

Single source of truth. There is a single store where your app contains the state that can be represented by an object tree.

State is read-only. When an action is emitted, the reducer function won’t update, but clone the current state and update it based on the action.

State changes are made with pure functions. You write the reducer function(s) that takes an action and the current state object, and returns a new state.

In Redux, the data flow is unidirectional:

1. The app component dispatches the action on the store
2. The reducer (a pure function) takes the current state object and then clones, updates, and returns it.
3. The app component subscribes to the store, receives the new state object and updates the UI accordingly.

This is how the Redux unidirectional data flow can be presented if used in a web app.

An action is a JavaScript object that has a property `type` describing what happened in your app, e.g. the user wants to buy the IBM stock. Besides the property type, and action object can optionally have another property with the payload of data that should somehow change the app state, for example:

{
type: 'BUY_STOCK',
stock: { symbol: 'IBM', quantity: 100}
}

This object only describes the action and provides the payload, but it doesn’t know how the state should be changed. Who does? The reducer.

A reducer is a pure function that specifies how the state should be changed. The reducer never changes the current state but creates a new (and updated) version of it. In other words, the state object is immutable. The reducer creates a copy of the state object and returns a new reference to it. If you use the Angular framework, it’s a binding change event, and all interested parties will immediately know that the state has changed without requiring expensive value checking in the entire state tree.

A reducer function has the following signature:

function (previousState, action): State {...}

Should the reducer function implement the app functionality like placing an order, which requires work with external services? Of course not, because reducers are meant for updating and returning the app state, e.g. the stock to buy is “IBM”. Besides, implementing the app logic would require interaction with the environment external to the reducer, i.e. it would cause side effects, and pure functions can’t have side effects.

The reducer can implement minimal app logic related to the state change. For example, the user decides to cancel the order, which requires a reset of certain fields on the state object. The main app logic remains in your application code (e.g. in services) unless a concrete implementation of the Redux-inspired library offers a special place meant for the code with side effects.

Why storing an app state in a single place is important

Recently, I was working on a project for a car manufacturer. This was a web app that allowed a prospective buyer to configure a car by selecting from tons of packages and options (e.g. model, interior and exterior colors, length of the chassis et al.) This app was developed for many years, the software modules were written using JavaScript, jQuery, Angular, React, Handlebars as well as the HTML templating engine Thymeleaf on the server. Nothing unusual, right?

From the user’s perspective, this was one workflow that consisted of several steps resulting in configuring and pricing the car based on selected options. But internally, this process was switching from one module to another, and each module would need to know what was selected in the previous step to show the available options.

In other words, each module would need to know the current state of the app. Depending on the software used in any particular module, the current user’s selections were stored using one of the following places:

New requirements were coming in, new JIRA tickets were created and assigned, and we’d start implementing them. Time and time again, implementing a seemingly simple new requirement would turn into a very time consuming and expensive task. Good luck in explaining to your manager why showing the price in page B would take a half day if this price was already known in page A. The thing is that the state object used in page B didn’t expect to have the price property, and if in page A the price was a part of the URL, page B was expecting to get the current state from the local storage.

Re-writing an app from scratch was not an option, but it would be so much easier if the app state was implemented in a uniform way and stored in a single place!

While the Redux is widely used in the web apps developed with the React framework, for Angular apps you can use the ngrx library that also implements the unidirectional data flow and can be used for implementing the app state management.
While the Redux API is simple, the ngrx is not. The reason is that ngrx is a combination of Redux and RxJS libraries that offers more than just keeping track of the round-trips between the UI and the app state. With ngrx, you can inject the code that communicates with external services into the data flow. Also, you can monitor the state of the router.

I’m planning to write a series of blogs to present ngrx, so it wouldn’t require a Ph.D. to master it. If you can’t wait, consider enrolling in our online workshop on using ngrx for state management in Angular apps. You’ll need to invest 7 hours of your time, but this may save you a lot more time in the long run.

After reading this blog, some of you may say that I was trying to shamelessly promote the book I’m working on, but this was not the goal of this write-up.

Over the years, I’ve authored and co-authored a number of books on programming. In two cases, the publishers asked me to write a second edition. In 2015, the second edition of my Java book was released by Wrox, and this year a second edition of the Angular book is about to be released by Manning.

IMO, the publisher asks the author to write a second edition of a programming book if the following statements are true:

1. The first edition was selling well, and the publisher sees an opportunity for additional revenues
2. A new version of the software has been released, and the first edition became outdated

When I was working on the second edition of my Java book, it became obvious to me that the quality of the materials in the second edition was much better than the first one. Why?

First, while writing a book you spend lots of time researching the subject. The second edition requires more research hence you understand the subject better.

Second, the errors do creep in no matter how many times you and technical editors go through the code samples; there is always something that can be improved or fixed.

Third, the readers of the first edition provide feedback. Some of the feedbacks are just mean (e.g one reader gave me one star on Amazon because the book arrived with scratches), but for the most part, the readers provide constructive criticism, which results in a better quality of the second edition.

Fourth, the more time you try to explain a subject to someone (in the books, blogs, classrooms, or conversations), the better you understand the subject.

Fifth, the readers have different perspectives and the real-world experience. Times and times again, I was saying to myself, “Oh, I didn’t think of it this way!” Re-write!

If you want to understand the subject, write a book about it.

My co-author Anton Moiseev and I are working on the last chapter of the second edition of our Angular book, and both of us are very happy with the results. My hat off to the editors of Manning Publications for nitpicking over tiny details and finding technical errors!

The first edition of this book was recently translated into Polish, Russian, Korean, and Chinese. It’s flattering, but unfortunately, the first edition is already one year old. Too old. Besides, the foreign publisher may hire translators who are not overly familiar with the subject, and the quality of the book suffers. Reading the book in the original language is always better.

If you made it this far, I want to thank you for reading all my ramblings. Check your bookshelf, and place some orders for the latest editions of your favorite software books!

Over the years, I was taking screenshots of error messages that are creative, funny, or just useless. Here’s my current collection. I’ll keep adding more images, but if you have your favorite error message, add its image in comments, and I’ll add it to this blog with proper credits.

I use the Yarn package manager for all my Angular projects. Besides being faster than npm, yarn creates a file yarn.lock that stores the exact versions of installed dependencies. Last year, I wrote about a specific use case that caused a breaking change during one of my Angular workshops.

Yesterday, I had to create a new project using Angular CLI. The project was successfully generated and started with ng serve. Then, I wanted to create a production build with ng build –prod, but the build failed with the error Cannot find module ‘uglifyjs-webpack-plugin’. I know that Webpack uses UglifyJS for optimizing sizes of the bundles, which is great, but my production build fails, which is not great at all.

The generated package.json file located in the root of my project has no direct dependency on uglifyjs-webpack-plugin, but there is one deep inside node_modules in one of the thousand (literally) dependencies used in Angular CLI projects.

To make the long story short, the WebPack team pushed to npmjs.org the new version 1.1.7 this plugin, which was empty. The Angular team got in touch with them, and an hour later, the fixed version 1.1.8 of the Webpack UglifyJS plugin was pushed to the npm central repo.

My project already had the yarn.lock file with an erroneous version of this plugin. I deleted it and ran yarn install again. This time it picked up the fixed 1.1.8 version and the ng build –prod command started working again. Thank you, the Webpack team for the quick turnaround! Happy end!

This was a specific issue with the newly generated project created at the “wrong time”. But imagine a team working on a project for some time, and their github repo didn’t include the yarn.lock file that stored the reference to the working version 1.1.6 of that plugin, and Mary (the QA engineer) decided to make a production build. A minute later, the entire team got an email titled “Who broke the build?”

The bottom line: Push the yarn.lock of the project that works and builds correctly into your version control system to ensure that the entire team has a reproducible and working build. This way, your project won’t depend on someone from across the globe submitting erroneous packages to the npmjs.org.

P.S. While npm 5 also creates the file package-lock.json with the registry of all installed dependencies, it doesn’t guarantee that each npm install will install exact versions of the packages listed there.

With Angular CLI, generating a new app and installing dependencies takes 30 seconds. Creating a production build takes another 15 seconds. And the best part is that the size of the deployed app can be as small as 55KB gzipped. Let’s do it.

1. Generate a minimalistic app with the inline template and styles with the following Angular CLI command:

ng new hello-world --minimal

2. If you’re not creating custom decorators and perform the AoT build, you don’t need to import the reflect polyfill, so comment out the following line in the generated file polyfills.ts:

import 'core-js/es7/reflect';

3. In the generated file app.component.ts remove most of the HTML markup from the component template so it looks as follows:

template: `Welcome to {{title}}!`

4. Make a production build (it performs the AoT compilation by default):

ng build -prod

5. The npm package serve is a small web server that can gzip static files on the fly. Install it globally:

npm install serve -g

6. Change to the dist directory where the application bundles were generated and serve the app (it’ll run on port 5000 by default):

Angular’s dependency injection mechanism allows us to cleanly separate business logic (services) from UI (components). What if our app generates a stream of values and we want to implement it as an injectable service? In this blog, I’ll create an injectable service that emits a stream of values and a UI component subscribes to this stream displaying its values real time.

In one of my RxJS blogs I showed you how to use the method Observable.create() providing an observer as an argument. Let’s create a service with a method that will take an observer as an argument and will emit the current time every second.

1. Return an observable stream of dates
2. Create an observable
2. Provide an observer
4. Emit the new date every second

In this service, we create an instance of the RxJS Observable object, assuming that the subscriber will provide an Observer that knows what to do with the emitted data. Whenever the observable invokes the method next(new Date()) on the observer, the subscriber will receive the current date and time. Our data stream never throws an error and never completes.

We’ll inject the ObservableService into the AppComponent, which invokes the method createObservableService() and subscribes to its stream of values, creating an observer that knows what to do with the data. The observer just assigns the received time to the variable currentTime which renders the time on UI.

1. Display the time using the date pipe
2. Inject the service that wraps the observable
3. Create the observable and start emitting dates
4. Subscribe to the stream of dates

This app doesn’t use any servers, and you can see it in action in the great Stackblitz online IDE here.

In the browser’s window, the current time will be updated every second. You use DatePipe here with the format ‘mediumTime’, which displays only hours, minutes, and seconds (all date formats are described in the DatePipe documentation).

This simple example demonstrates a basic technique for wrapping any application logic in an observable stream and subscribing to it. In this case, we use setInterval(), but you could replace it with any application-specific code that generates one or more values and sends them as a stream.

Don’t forget about error handling and completing the stream if need be. The following code snippet shows a sample observable that sends one element to the observer, may throw an error and tells the observer that the streaming is complete:

If you uncomment the line with a throw, observer.error() is invoked, which results in the invocation of the error handler on the subscriber if there is one.

The data producer for our observable stream was generating date/time but it could be any app code that generates some useful values, e.g. a WebSocket server generating stock quotes, auction bids, actions of online game players, etc. During my workshops, I show a sample online auction app that has a Node server emulating users’ bids on products. That server uses a WebSocket connection to push new bids for products to all users that are interested in receiving them.