Unfortunately, there is no NodeJs 14 that is built for ARM64; Hence it has no support for the new Mac Silicon which is built around ARM64.

Fortunately, there is some workaround to get NodeJs 14 to work with Mac Silicon. Apple provides Rosetta, a translation app that allows applications that are built for Intel Chip (or previous generation Mac) to run under Apple Silicon.

Installing Rosetta

To install Rosetta, you need to:

1. Open your terminal

2. Paste and execute /usr/sbin/softwareupdate --install-rosetta --agree-to-license

And that's it!

Installing NodeJs 14

For any Node installation in Mac, I recommend you to use NVM. It allows you to easily swap between Node versions through CLI.

To install NVM:

1. Open your terminal

2. Paste and execute curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

3. Restart your terminal

You can confirm that NVM has been successfully installed by executing nvm command in your terminal.

Now, to get to the real deal on installing NodeJs 14, we will execute everything through terminal.

1. Open your terminal

2. Execute arch and confirm that at the moment it is returning arm64

3. Execute arch -x86_64 zsh

4. Execute arch and confirm that it is now returning i386

5. Execute nvm install 14. NVM will install the latest NodeJs 14.

6. Execute nvm use 14 to switch to NodeJs 14, if you have other NodeJs versions installed.

That's it, folks! You now are able to use NodeJs 14 with your new Mac.

But first, what is RxJS?

RxJS is a library for composing asynchronous and event-based programs by using observable sequences - RxJS

Since RxJS is baked into Angular we are so used to the fact we need to subscribe for us to receive data from our various services, e.g. HttpClient, NgRx Store or event.

What is a Subscription?

To understand what a Subscription is, we need to first understand several terminologies in RxJS.

Observable

According to RxJS docs, Observable is a representation of any set of values over any amount of time.
Observable has subscribe() method, which invokes the execution of an Observable and registers Observer handlers for notifications it will emit.

Subscription

Now that we understand Observable and subscribe() method, now we are ready to talk about Subscription. In a nutshell, a Subscription:

• Is a disposable resource, usually the execution of an Observable (allowing value to be streamed out of observable)

• There is one important method, unsubscribe(), which disposes of the resource held by the Subscription

Sample use case

You have a Web API available that provides endpoints for adding, editing, and retrieving Todo Items. Now you want to display these Todo items in an application.

To get all the data, we have to:

1. Send an HTTP request

2. Subscribe to the Observable using subscribe() with a fat arrow function that will eventually receive the todo item payload

3. Inside our fat arrow function, we can assign the incoming todo item to a local variable (which will/can trigger a UI update)

this.httpClient
    .get('https://jsonplaceholder.typicode.com/todos')
    .subscribe((todos) => {
      ...
    });

It would be nice always to have the latest data. We can continually fetch the new data by polling the endpoint every 10 seconds.

interval(10000).subscribe(() => {
      this.httpClient
        .get('https://jsonplaceholder.typicode.com/todos')
        .subscribe((todos) => {
          ...
        });
      });

However, little did we know that our code above was doing more than we intended. We somehow ended up bombarding the server with request after a few navigations back and forth. It went from fetching once every 10 seconds to once every a few seconds, and sometimes double fetching occurred.

Up to this point, we now realised that even if the component gets destroyed, the subscription will remain until we told them otherwise.

Solutions

1. Unsubscribe all Subscriptions

I think this sounds like the most sensible way when we think about the subscription.
Of course, all subscription needs to be unsubscribed for it to be stopped.

Unsubscribe single subscription

ngOnInit() {
  // Assign the subscription to a variable
  this.subscription = interval(10000).subscribe(() => {
    ...
  });
}

ngOnDestroy() {
  // Manually unsubscribe subscription on ngDestroy life-cycle
  this.subscription.unsubscribe();
}

Unsubscribe multiple subscriptions in an array

ngOnInit() {
  // Push every subscriptions to an array of subscriptions
  this.subscriptions.push(
    interval(10000).subscribe(() => {
      ...
    })
  );
}

ngOnDestroy() {
  // Loop on every subscriptions and unsubscribe
  this.subscriptions.forEach((subscription) => {
    subscription.unsubscribe();
  });
}

2. Completing Subscription using RxJS pipe

Before we head into RxJS pipe, let us first understand what a pipe is. It is not the same as a pipe with the symbol of |. Pipe in RxJS is a chain of Pipeable Operators, which is a pure function that takes an Observable as an input and emits a new Observable as the output (read more).

There are various ways to complete RxJS through pipe. I'll share my top three operators.

take()

take operator lives up to its name. It will only take a number passed through the function and then unsubscribe itself.

ngOnInit() {
  interval(10000)
    // Take 10 values then unsubscribe the stream
    .pipe(take(10))
    .subscribe((x) => {
      ...
    });
}

takeWhile()

takeWhile operator will unsubscribe the Observable stream when the function call inside takeWhile returns false.

private _componentExist = true;

ngOnInit() {
  interval(10000)
    // takeWhile pipe will accept stream as long as the value returns true.
    // When the value is false, it will terminate the stream
    .pipe(takeWhile(() => this._componentExist))
    .subscribe(() => {
      ...
    });
}

ngOnDestroy() {
  this._componentExist = false;
}

Do notice that if the Observable stream does not emit any new value, the subscription will never be terminated, since the takeWhile operator requires a stream to pass through to terminate itself.

takeUntil()

takeUntil will accept any streamed values until the Observable function in the takeUntil emits a value. You might want to use this approach when the two approaches above do not suit your use case.

private ngDestroy$ = new Subject();

ngOnInit() {
  interval(10000)
    .pipe(takeUntil(this.ngDestroy$))
    .subscribe((x) => {
      ...
    });
}

ngOnDestroy() {
  // Emit value to make all takeUntil gets triggered
  this.ngDestroy$.next();
  // Then complete its own subscription to make sure there is no loose end
  this.ngDestroy$.complete();
}

3. Use Angular async pipe

Angular comes with an amazing async pipe, which allows an observable value to be streamed directly into the html template. The benefit of this approach is that you dont have to manage anything. Angular will manage it for you, and it will follow the component's life cycle.

TS:

todos$: Observable<Todo[]>;

ngOnInit() {
  this.todos$ = interval(10000).pipe(
    ...
  );
}

HTML:

<ul>
  <li *ngFor="let todo of (todos$ | async)">
    {{ todo | json }}
  </li> 
</ul>

Summary

Make sure you terminate all RxJS subscriptions. You have seen that in a small-scale application, an unterminated subscription can cause some unwanted effects. Imagine what could happen in an enterprise app where there are so many subscriptions happening.

We've learnt that in Angular, you can terminate a subscription either by:

1. Unsubscribe all subscriptions manually

2. Completing Subscription using RxJS pipe:
   a. take operator
   b. takeWhile operator
   c. takeUntil operator

3. Use Angular async pipe and let Angular do it for you

Each of them has their strong points. You need to know when to use it according to your own needs.

Personally, I would recommend using async when the data stream is only being used in the HTML template and use takeUntil if the data is being used in the component. You definitely can mix the usage according to your circumstances.

Now we can all have a fun time with subscriptions!

1. CSS was written in such a specific way (sometimes too specific).

2. Inconsistencies in how devs write CSS classes. The default standard for most CSS should be written in kebab-case. But I have seen a mixture of kebab-case, camelCase, and also TitledCase in a single project.

3. Blindly implementing the whole Bootstrap framework as well as trying to keep own branding. I have seen teams import bootstrap.min.css then try hard to override those stylings that they don't like.

So, here are a few tips that can reduce the pain of writing CSS:

1. Be consistent

Most front-end developers type CSS in all lower-case with - (hyphen) as the separator between words (e.g.: .table-heading). But, if your team has already done a camel case or titled case, make sure everything stays consistent.

2. Make reusable classes

The idea of writing CSS is to make them as reusable as possible to reduce the need for repeating the same code.
Avoid writing CSS like:

div#card {
    background-color: #eee;
    color: #000;
    text-align: center;
}

Write it in a more reusable way:

.card {
    background-color: #eee;
    color: #000;
    text-align: center;
}

You can further normalise the CSS for further reusability:

.bg-grey {
    background-color: #eee;
}

.color-black {
    color: #000;
}

.text-center {
    text-align: center;
}

You never know when you are going to reuse it. Making it specific to a particular ID is a bad practice because HTML can only have one element that has the same ID. Coupling CSS to ID makes it not reusable. Only target it to a specific ID if you are sure that you are only going to use that specific CSS styling for that specific element.
Do notice that if you are using Bootstrap, some of the CSS utility classes are available out of the box.

3. Use CSS pre-processor

There are various CSS pre-processors available out there.

1. Sass

2. LESS

3. Stylus

4. PostCSS

For a small project, it might not be required. But when you are working on an enterprise-level project, styling consistencies are very important. CSS pre-processors help to keep your CSS DRY (Don't Repeat Yourself) by allowing you to keep commonly used things (like colours and stylings) in one place and make them reusable. Here are how we can leverage the benefits of CSS pre-processors:

1. Use variables. Variables allow you to reuse certain values like margin or colour throughout your application. Example in Sass (SCSS):

$blue: #00f;
$default_margin: 1rem;

.bg-blue {
    // Background color will be *#00f* once processed
    background-color: $blue; 
}

.container {
    margin: 0 $default_margin;
}

2. Use Mixins for some reusable sets of styles. Example in LESS:

.rounded-border {
    border: 1px solid;
    border-radius: 4px;
}

// To produce CSS for black border with rounded corner
.black-rounded-border {
    border-color: #000;
    .rounder-border();
}

// To produce CSS for blue border with rounded corner
.blue-rounded-border {
    border-color: #00f;
    .rounded-border();
}

3. You can easily change the base variable for some UI frameworks like Bootstrap and Material. Changing the base variable prevents the need to override CSS to suit your branding, e.g., font size, padding, margin, and also default colours. You need to make sure that you import the pre-processed CSS file (e.g.: .scss), not the compiled .css file.

4. Avoid !important !

Using !important can make your life hard. By default, any CSS property with !important takes precedence over any other CSS styling that is put into that particular component. It looks fine until you need to override that style that has !important. You will have to write a more specific CSS rule just so you can override it with another !important.

Instead, write CSS in either:

1. Use specificity as much as possible. Rather than relying on !important tag, use any available parent's component or classes of the element to be the additional hook. e.g.:

.form-control {
    border: 1px solid grey;
    border-radius: 0.5rem;
}

.squared.form-control {
    border-radius: 0;
}

.seamless .form-control {
    border: 0;
}

Don't fall into this rabbit hole of !important like the example below:

.form-control {
    border: 1px solid black!important;
}
input.form-control {
    border: 1px solid blue!important;
}
.parent-class input.form-control {
    border: 1px dotted green!important;
}
#main-content .parent-class input.form-control {
    border: 1px dashed #eee!important;
}

2. If by any chance you are using some JavaScript framework like React, Vue, or Angular; you can use scoped CSS. Scoped CSS allows us to create a CSS specific to a particular component. It can be achieved by using some attributes appended to HTML elements.

By having a scoped CSS, you have less specificity to worry about, since you don't necessarily need to override a CSS styling that is targeted for another component. All you need is to override base styling if required.

These are a few things that I've used in projects to improve the quality of our CSS. Sometimes you might think that using a pre-processor like SCSS seems overkill for your project. However, the benefits of simplicity and consistency outweigh the learning curve and setup time. I hope you've learned something from these tips. Have you got any CSS tips that I've missed? Please do let me know in the comment section below.

P.S.: If you are ready to see the rabbit hole, CSS Cascade is a great resource about how CSS style 'cascades'.

Cheers!

For an Angular developer that uses NgRx, we often get this dilemma of which type of map should we use upon receiving NgRx action for our effect. This issue also happens in any services or functions that rely on observable value change. I'm going to explain and give a small code sample to show you what is the difference of each.

Switch Map

switchMap is probably something that you see very often in a lot of code samples. It has a unique behaviour of switching from one to another as the name explains.
Theoretically speaking, what it does is: when a next value pushed to the observable, it will cancel previous observable and take the current one instead.

Merge Map

mergeMap also lives up to its name. Its behaviour allows multiple observable values to be merged and each will run concurrently. Sometimes this behaviour is needed but proceeds very carefully with mergeMap. In many times, mergeMap causes race conditions. Use this map only if you know the incoming data will not override each other.

Exhaust Map

When I first hear the word exhaustMap, I don't understand what is the concept of the naming. Then my friend explained it and it blew my mind! exhaustMap will prevent any data from going through if the previous observable is not yet completed. This means, whatever data you force into that observable will just get dropped. Not even queued.

Concat Map

At this stage, you might think, so there is no queueing system with observable data? At ease crowd, concatMap comes to the rescue. As the name explains, concatMap will append observable data from one to another. It will create a queue that will run when the previous data has been completed.

I have created a repository on GitHub for these various map samples. It may not be the best looking, but it works. If you have any suggestions to make it look nicer and easier to visualise, please don't hesitate to give me feedback.

Initially, I was quite surprised that ng update I could easily upgrade my .NET Core 2.1 RC Angular SPA template without any hitch, except the fact I needed to install the TypeScript version 2.7.2 as one of the pre-requisite. Then the ng update @angular/cli blew my mind too, as it automatically converts my angular-cli.json and its content into the new angular.json with the new structure. Alas, the excitement didn't last long. I decided to give my existing project a try for ng update. The result? Unsatisfying.

Imagine that you're a kid in the first few queues in the front of a candy shop. Right at 10 AM sharp, the store is open. One by one people entered and brought out a bag of candies that you've been waiting for. Once you're in front of the door, you are not allowed to enter, because you have to be older than your age and have a certain height and weight requirements. That is how it feels when you realise that there are so many restrictions that prevent your ng update from working. Below is a snippet of my ng update command.

C:\source\upgrade-sample (master -> origin)
 ng update
    We analyzed your package.json, there are some packages to update:

      Name                               Version                  Command to update
     --------------------------------------------------------------------------------
      @angular/core                      5.2.2 -> 6.0.1           ng update @angular/core
      rxjs                               5.5.2 -> 6.1.0           ng update rxjs


    There might be additional packages that are outdated.
    Or run ng update --all to try to update all at the same time.


C:\source\upgrade-sample (master -> origin)
 ng update --all
                  Package "karma-jasmine-html-reporter" has a missing peer dependency of "jasmine" @ ">=3".
                  Package "bootstrap" has a missing peer dependency of "jquery" @ "1.9.1 - 3".
                  Package "@angular/compiler-cli" has an incompatible peer dependency to "typescript" (requires ">=2.7.2 <2.8", would install "2.8.3").
                  Package "@ng-idle/core" has an incompatible peer dependency to "@angular/common" (requires "^4.0.0 || ^5.0.0", would install "6.0.1")
                  Package "@ngrx/router-store" has an incompatible peer dependency to "@angular/common" (requires "^5.0.0", would install "6.0.1")
                  Package "@ng-idle/keepalive" has an incompatible peer dependency to "@angular/common" (requires "^4.0.0 || ^5.0.0", would install "6.0.1")
                  Package "@ngrx/store-devtools" has an incompatible peer dependency to "rxjs" (requires "^5.5.0", would install "6.1.0")
                  Package "@ngrx/store" has an incompatible peer dependency to "@angular/core" (requires "^5.0.0", would install "6.0.1")
Invalid range: ">=6.0.0-rc.0"

Looking at the snippet, I sort of realised that I will end up updating my package manually and one-by-one. Such a tedious task.
Nevertheless, I believe one day ng update command will be very smart that it will be able to check all package dependencies and update the package.json smartly.