In this post, we are going to look at four important features in angular that can help you during your app development life cycle. These features are there but are mainly not openly advertised unless you go out looking for them. This is not because they are not useful but can be quite difficult to use for beginners and not entirely needed for small project.

Angular CLI Budgets

This is a simple but quite useful feature for Angular. Basically, you specify a baseline size you expect for various parts of your angular app. Then, set how much the size of your parts should deviate from the baseline – a threshold – both minimum and maximum. And during compilation, Angular CLI will check the output artefacts against the configuration and warn you when you are over or under the budget you set. This feature ensure that the final output of angular projects meets your expectation – in terms of expected bundle sizes. This saves you from having to breakout the bundle analysis tool on each production build. You only have to analyze the bundle when you are over or under budget to try and understand why.

Usage

The budget configurations are set inside angular.json under the environment  you wish to enforce your budgets for:

// angular.json
{
  //...
  "configurations": {
    "production": {
      //...
      "budgets": [
        {
          "type": "bundle", // check allowed types below
          "name": "vendor",
          "baseline": "750kb", // baseline size for comparison. (size in b, kbs, mbs. **No percentage allowed here**)
          "warning": "100kb", // threshold for warning relative to baseline. **Can also be in percentage**.
          "error": "200kb" // threshold for error relative to the baseline. **Can also be in percentage.**
        }
      ]
    }
  }
}

NB: You provide the baseline size of the application and then provide values of how much the size can deviate from the that baseline, from a maximum and minimum value. In our configuration above, you get a warning if it deviates from the baseline by 100kb and an error if it deviates by 200kb.

Allowed Types are:

• bundle - The size of a specific bundle.
• initial - The initial size of the app.
• allScript - The size of all scripts.
• all - The size of the entire app.
• anyScript - The size of any one script.
• any - The size of any file.

Code Coverage

The second feature is for testing angular apps (angular code base). When running tests in Angular CLI, using ng test, you can enable code coverage reports. They allow you to see which parts of the code base has not been tested properly. To generate a code coverage report, you must pass --code-coverage flag when running tests:

ng test --watch=false --code-coverage

You can also enable it by default in angular.json to allow code coverage reports to be generated by default:

// ...
"test": {
  "builder": "@angular-devkit/build-angular:karma",
  "options": {
    "main": "src/test.ts",
    "polyfills": "src/polyfills.ts",
    "tsConfig": "src/tsconfig.spec.json",
    "karmaConfig": "src/karma.conf.js",
    "styles": ["src/styles.css"],
    "scripts": [],
    "assets": ["src/favicon.ico", "src/assets"],
    "codeCoverage": true // <== Code Coverage Reports Here
  }
},
//...

Now, the neat part is that you can enforce Code Coverage in your Angular Application. For instance, if you wanted 80% of your code to be covered, all you have to do is open karma.conf.js and add the following content in the coverageIstanbulReporter property:

coverageIstanbulReporter: {
  reports: ['html', 'lcovonly'],
  fixWebpackSourcePaths: true,
  thresholds: {
    statements: 80,
    lines: 80,
    branches: 80,
    functions: 80
  }
}

NB: The threshold property will enforce a minimum of 80% code coverage for each of the items under threshold when unit tests are run in the project.

Generating an App Shell

The third feature in this list, is for performance optimization. The app shell or application shell is the minimum CSS, HTML and JavaScript required to power UI for an application. The goal here is to provide as fast as possible a shell of your app (i.e. navigation, footer, header, loading bar etc.) – as the rest of the content is being loaded after initialization. The performance is further improved when cached offline (using service workers) for returning users, giving them near native performance improvement.

NB: An application shell (or app shell) architecture is one way to build a Progressive Web App that reliably and instantly loads on your users’ screens, similar to what you see in native applications.

Angular provides a feature to generate a prerendered app shell for your application for a specific route. This allows users to see a very fast paint, as the app is being loaded. Once initialized, the default view can be replaced with intended content. The prerendered page is loaded with the initial http response from the server together with the index.html. Since its route specific, this will result in more page specific resources being loaded initially. Since, this is a long but useful feature, I am going to recommend the following tutorial from Angular University. You can also learn more about App Shell here.

Hot Module Replacement (HMR)

Our final feature is a webpack feature that can be enabled for angular. This feature allows for modules to be replaced without need for a full browser refresh. This allows you to retain much of the application state, usually lost when reloading. It also saves you valuable times by only updating what has changed. And changes to the code reflect almost instantly, like when you are messing with dev tools on the browser. I previously covered this feature in details here – You will be able to run how to enable and use this feature in Angular.