DEV Community: Suguru Inatomi

Building Browser Extensions with WXT + Angular

Suguru Inatomi — Mon, 12 Jan 2026 09:08:00 +0000

I created a starter template for developing browser extensions by combining WXT and Angular. You can efficiently develop extensions for multiple browsers including Chrome and Firefox using Angular’s latest features.

lacolaco / wxt-angular-starter

Browser extension starter template using WXT and Angular

WXT + Angular Starter

A browser extension starter template using WXT and Angular.

Features

Angular 21 with zoneless change detection
Tailwind CSS v4 for styling
WXT for cross-browser extension development
Vite 7 powered build system
TypeScript with strict mode

Quick Start

# Clone the repository
git clone https://github.com/user/wxt-angular-starter.git
cd wxt-angular-starter

# Install dependencies
pnpm install

# Start development server (Chrome)
pnpm dev

# Start development server (Firefox)
pnpm dev:firefox

Available Scripts

Script	Description
`pnpm dev`	Start dev server for Chrome
`pnpm dev:firefox`	Start dev server for Firefox
`pnpm build`	Build for Chrome
`pnpm build:firefox`	Build for Firefox
`pnpm zip`	Build and package for Chrome
`pnpm zip:firefox`	Build and package for Firefox
`pnpm compile`	Type-check without emitting

Project Structure

├── entrypoints/
│   ├── popup/          # Angular popup entrypoint
│   │   ├── index.html
│   │   ├── main.ts     # Angular bootstrap
│   │   ├── app.ts      # Root component
│   │   └── style.css

…

View on GitHub

What is WXT

https://wxt.dev/

WXT is a framework that streamlines browser extension development. Built on Vite, it provides a comfortable development experience with fast HMR (Hot Module Replacement) and a file-based manifest auto-generation system.

Particularly useful is its ability to generate extensions for multiple browsers including Chrome, Firefox, Edge, and Safari from a single codebase. It supports both Manifest V2 and V3, absorbing browser-specific differences.

Building Browser Extensions with Angular

For the UI part of browser extensions, you’ll be loading HTML. WXT officially supports several libraries. When you run the wxt init command, you can choose templates like Vanilla, React, or Vue, but there’s no Angular template yet. However, the setup isn’t too difficult - you can simply configure Angular on top of the Vanilla base.

Note that to run Angular with Vite, you need the @analogjs/vite-plugin-angular plugin. This plugin is provided by the AnalogJS project and enables Angular to work within the Vite ecosystem.

https://www.npmjs.com/package/@analogjs/vite-plugin-angular

Project Structure

The starter template has the following structure:

├── entrypoints/
│ ├── popup/ # Angular popup interface
│ │ ├── index.html
│ │ ├── main.ts # Angular bootstrap
│ │ ├── app.ts # Root component
│ │ └── style.css # Tailwind CSS
│ ├── background.ts # Background script
│ └── content.ts # Content script
├── wxt.config.ts # WXT configuration
├── tsconfig.json # Base TypeScript config
└── [tsconfig.app](http://tsconfig.app/).json # Angular-specific config

In WXT, manifests are automatically generated from files in the entrypoints directory. The popup directory serves as the entry point for the Angular application, while background.ts and content.ts can be written in plain TypeScript.

Setup Steps

Here are the steps to build from scratch.

1. Initialize WXT Project

First, create a WXT project:

pnpm dlx wxt@latest init my-extension
cd my-extension

2. Install Dependencies

Install Angular core and build tools:

# Angular core
pnpm add @angular/core @angular/common @angular/compiler @angular/platform-browser rxjs

# Build tools
pnpm add -D @analogjs/vite-plugin-angular @angular/build @angular/compiler-cli

# Tailwind CSS (optional)
pnpm add -D tailwindcss @tailwindcss/vite

3. Pin Vite Version

Since @analogjs/vite-plugin-angular requires Vite 7.x, pin the version in package.json:

{
  "pnpm": {
    "overrides": {
      "vite": "^7.3.0"
    }
  }
}

After adding this, run pnpm install to apply the version.

4. Configure WXT

Configure Vite plugins in wxt.config.ts:

import { defineConfig } from 'wxt';
import angular from '@analogjs/vite-plugin-angular';
import tailwindcss from '@tailwindcss/vite';

export default defineConfig({
  vite: () => ({
    resolve: {
      mainFields: ['module'], // Prioritize ESM
    },
    plugins: [
      angular({
        tsconfig: '[tsconfig.app](http://tsconfig.app/).json',
        // Limit Angular compilation to specific entrypoints
        transformFilter: (_code: string, id: string) => {
          return id.includes('/entrypoints/popup/');
        },
      }),
      tailwindcss(),
    ],
  }),
});

The key is the transformFilter configuration. This ensures that only files in the entrypoints/popup/ directory are processed by the Angular compiler. Background and content scripts are treated as plain TypeScript, allowing coexistence of code that doesn’t use Angular.

5. Configure TypeScript

Separate project-wide configuration from Angular-specific configuration.

tsconfig.json (project-wide):

{
  "extends": "./.wxt/tsconfig.json",
  "compilerOptions": {
    "experimentalDecorators": true,
    "useDefineForClassFields": false
  },
  "angularCompilerOptions": {
    "strictInjectionParameters": true,
    "strictInputAccessModifiers": true,
    "strictTemplates": true
  }
}

tsconfig.app.json (Angular-specific):

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ES2022",
    "moduleResolution": "bundler",
    "lib": ["ES2022", "DOM"],
    "strict": true,
    "experimentalDecorators": true,
    "useDefineForClassFields": false,
    "skipLibCheck": true,
    "isolatedModules": true
  },
  "angularCompilerOptions": {
    "strictInjectionParameters": true,
    "strictInputAccessModifiers": true,
    "strictTemplates": true
  },
  "include": ["entrypoints/popup/**/*.ts"]
}

The include limits the files processed by the Angular compiler. If you want to use Angular in other entrypoints like options pages, add them here.

6. Create Angular Popup

Finally, create the entry point for the Angular application.

entrypoints/popup/index.html:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>My Extension</title>
    <meta name="manifest.type" content="browser_action" />
  </head>
  <body>
    <app-root></app-root>
    <script type="module" src="./main.ts"></script>
  </body>
</html>

entrypoints/popup/main.ts:

import './style.css';
import { bootstrapApplication } from '@angular/platform-browser';
import { provideZonelessChangeDetection } from '@angular/core';
import { App } from './app';

bootstrapApplication(App, {
  providers: [provideZonelessChangeDetection()],
}).catch((err: unknown) => console.error(err));

entrypoints/popup/app.ts:

import { ChangeDetectionStrategy, Component } from '@angular/core';

@Component({
  selector: 'app-root',
  changeDetection: ChangeDetectionStrategy.OnPush,
  host: { class: 'block p-4' },
  template: `
    <h1 class="text-lg font-bold">Hello from Angular!</h1>
  `,
})
export class App {}

entrypoints/popup/style.css:

@import 'tailwindcss';

Since we’re now on Angular v21, I’m using provideZonelessChangeDetection() to enable change detection without Zone.js. In limited environments like browser extensions, Zone.js overhead is often wasteful, so this reduces bundle size and minimizes runtime overhead.

Development and Build

Once setup is complete, you can start the development server:

# Chrome dev server
pnpm dev

# Firefox dev server
pnpm dev:firefox

For production builds and packaging:

# Chrome build
pnpm build

# Firefox build and ZIP
pnpm zip:firefox

Summary

Combining WXT and Angular enables modern browser extension development. The appeal is being able to leverage both WXT’s excellent developer experience and Angular’s powerful features. Using this starter template, you can start development immediately without the setup hassle.

The repository mentioned at the beginning is published as a GitHub template repository, so if you’re interested, click Use this template on the repository to create your own browser extension.

Understanding Angular Ivy Library Compilation

Suguru Inatomi — Wed, 24 Feb 2021 07:13:34 +0000

Original Post: https://blog.lacolaco.net/2021/02/angular-ivy-library-compilation-design-in-depth-en/

In this post, I will explain how to compile Angular libraries with Ivy, which is now possible in Angular v11.1, and its details. The intended audience is those who are developing Angular third-party libraries, or simply interested in Angular’s internal mechanism. You don’t need to know anything in this article to develop Angular applications.

The content of this article is based on the Design Doc written by the Angular team.

Ivy Library Compilation - Conceptual Design Doc

How to compile libraries with Ivy

When you develop an Angular library using Angular CLI or something similar, Ivy is currently disabled for production build. It is probably set in a file like src/tsconfig.lib.prod.json as follows.

{
  "angularCompilerOptions": {
    "enableIvy": false
  }
}

Angular libraries compiled and published to NPM with this configuration are still compatible for use even if the applications are not Ivy-enabled.

Starting from Angular v11.1, you can experimentally remove compatibility for applications not yet Ivy-enabled, and compile the library optimized for Ivy-enabled applications. To use Ivy compilation for libraries to be published to NPM, configure as follows

{
  "angularCompilerOptions": {
    "enableIvy": true,
    "compilationMode": "partial"
  }
}

"compilationMode": "partial" is an important part, and I will explain what it means in the later part of this post. Of course, libraries compiled with this setting can only be used in Ivy-enabled applications, so it is still not currently recommended.

By the way, for libraries that are only used locally in monorepo, such as Angular CLI and Nrwl/Nx, you can simply use enableIvy: true. The "compilationMode": "partial" is required only for the libraries that are published in NPM. This difference is also explained later in this article.

{
  "angularCompilerOptions": {
    "enableIvy": true
  }
}

Terminology

In order to make the following explanations concise, let’s first sort out the terminology.

term	meaning
Angular decorators	Decorators defined by Angular such as `@Component`, `@Directive`, and `@Injectable`.
Compiler	The Angular compiler is a tool that analyzes Angular decorators and generates executable code.
`ngc`	An executable CLI for the Angular compiler
Ivy compiler	A compiler introduced in Angular v9
View Engine (VE) compiler	A deprecated compiler that was used by default until Angular v8

Ivy compilation for applications

Before we start talking about libraries, let’s start with compiling an application with Ivy already enabled by default. The Angular decorator in the application will be analyzed by the compiler to generate the executable code based on the extracted metadata.

Let’s look at an example of compiling a simple component. Suppose we have the following component.

@Component([
  selector: 'some-comp',
  template: `<div> Hello! </div>`
})
export class SomeComponent {}

If you compile this code with Ivy, you will get the following JavaScript output. The two points are as follows

The decorator does not remain in the JavaScript.
The generated code is inserted as a static field in the component class.

export class SomeComponent {}
SomeComponent.ɵcmp = ɵɵdefineComponent({
  selectors: [['some-comp']],
  template: (rf) => {
    if (rf & 1) {
      ɵɵelementStart('div');
      ɵɵtext(' Hello! ');
      ɵɵelementEnd();
    }
  },
});

The Ivy compiler generates the code to create the definition from the metadata contained in the decorator. The HTML template, which was a string, becomes executable code as a Template Function. The ɵɵelementStart and ɵɵtext used in the template functions are called Template Instructions , and abstract the concrete DOM API calls and data binding update process.

Angular compilation is internally divided into two steps; Analysis step and code generation step.

Analysis step

In the analysis step of compilation, it integrates the metadata obtained from the decorators of the entire application and detects the dependencies between components/directives. At this point, the important part is the @NgModule. It is used to determine the references corresponding to unknown HTML tags and attributes contained in templates. After the analysis step, the compiler gets the following information.

Which components depend on which directives/components
What dependencies are needed to instantiate each component/directive

Code generation step

In the code generation step, it generates the code for each Angular decorator based on the information obtained in the analysis step. The generated code has two requirements: Locality and Runtime Compatibility.

Locality

Locality is also expressed as self-contained. It means that all the references needed for compiling the component are included in the component class itself. This makes differential builds more efficient. To make it easier to understand, let’s look back at the issues in the pre-Ivy View Engine days without Locality.

The VE compiler generated code as a file named *.ngfactory.js which was independent of the original file. Angular executes this *.ngfactory.js at runtime, and the generated code refers to the original component class. This approach becomes problematic when a component depends on another component.

For example, when a component <app-parent> uses a template to call a component <app-child>, there is no reference from parent.component.ts to child.component.ts as a JavaScript module. This parent-child dependence is only visible between parent.component.ngfactory.js and child.component.ngfactory.js.

Since the direct compilation result, parent.component.js, does not refer to either child.component.js or child.component.ngfactory.js, it cannot determine when it needs to be recompiled. Therefore, ViewEngine had to recompile the entire application at each build time.

To solve this problem, the Ivy compiler generates the code as a static field of the class. In the generation code, the classes of the directives referenced in the template are included. This makes it easy to determine which files will be affected when that file is changed.

As you can see, with code generation with Locality, it is only necessary to recompile ParentComponent when itself or ChildComponent is changed.

// parent.component.js
import { ChildComponent } from './child.component';

ParentComponent.ɵcmp = ɵɵdefineComponent({
    ...
    template: function ParentComponent_Template(rf, ctx) {
        if (rf & 1) {
            ɵɵelement(2, "app-child");
        }
    },
    // Directives depended on by the template
    directives: [ChildComponent]
});

Runtime compatibility

Another important factor in code generation is runtime compatibility. This is not an issue when compiling an application, but it is critical for compiling a library.

In an application, the compiler version and the Angular runtime version basically match because the compilation is done at the same time in the application build. However, this is not the same for libraries.

For libraries published to NPM, it must be considered that the Angular version that compiles the library does not match the Angular version used by the application that uses the library at runtime. A big issue here is the compatibility of the Angular APIs called in the generated code. APIs that existed in the compile-time version may not exist in the runtime version of Angular, or their signatures may have changed. So, the rules for code generation must be determined by the Angular version of the runtime that executes it.

Libraries used locally within monorepo were Ivy compilable because as long as it is in monorepo, it is ensured that the library and the application have the same Angular version.

Library compilation

Here is the main topic. First, let’s look at compiling libraries with enableIvy: false, which is the current recommended setting for v11. Compiling a library with no Ivy is just inlining the metadata collected in the analysis step. The Angular decorator metadata is embedded in the static field as shown below.

The library compilation works to convert the metadata into a JavaScript representation that can be published to NPM. However, this is still a metadata and cannot be executed as a component when loaded into an application. It needs to be compiled again based on this metadata. Angular Compatibility Compiler , ngcc, is the tool to do it.

ngcc

As we don’t know whether the application side compiler is Ivy or VE, the only way to keep compatibility is to compile the library code on the application side. This is the reason why ngcc is run at application build time.

The compilation result of ngcc is the same as that of compiling the library directly. The difference is that ngc uses decorators in TypeScript as metadata, while ngcc uses .decorators in JavaScript as metadata.

Although ngcc achieved its purpose to allow libraries to be released to NPM with compatibility, the frequent compilations spoiled the developer experience. Many of you may have felt the frustration of running ngcc repeatedly every time you installed a library. The ngcc overwrites the library code in node_modules installed from NPM and compiles it, so if the contents of node_modules are changed by the npm install command, you have to recompile it.

But originally, ngcc is a temporary approach until the View Engine support is removed from applications. The Ivy library compiler, which will be explained below, is a new Ivy-native library compilation mechanism that solves the problems clarified by ngcc.

Ivy library compilation

The biggest issue with ngcc was the execution cost of the compilation on the application side. If ngcc was fast enough, we could have compiled the library just-in-time when the application was compiled, without persisting the compilation results in node_modules. The execution cost is high, so we want to reduce the number of times and save the results.

On the other hand, if we finish compiling the library before publishing it, we can build the application faster, but we lose runtime compatibility. The code generation step really needs to be done in the application’s Angular version.

So Ivy library compilation concept is a set of mechanism for running only the code generation step rapidly after library installation and mechanism for finishing the analysis step before NPM release. The first mechanism is called library linking , and the second mechanism is called Link-Time Optimization (LTO) compilation.

LTO compilation (Pre-Publish compilation)

LTO compilation, which is done before publishing to NPM, is a mechanism to complete only the analysis step of the entire compilation and embed the result in JavaScript. As mentioned in the Introduction, when the setting "compilationMode": "partial" is set, the compiler will perform LTO compilation of the library.

{
  "angularCompilerOptions": {
    "enableIvy": true,
    "compilationMode": "partial"
  }
}

The compiled JavaScript contains the following code. It looks similar to the normal compilation result, but the important thing is that the template is preserved as a string and it has Locality.

The information obtained from the analysis step is inlined as a declaration. It includes a list of directives on which it depends, and has a locality that allows it to execute the code generation step with only information in the file. And by deferring the code generation of template functions until they are linked, the library can ensure runtime compatibility.

Also, the Angular version of the LTO compilation is included. Even if the template is the same, it can be optimized at link time depending on the combination of both the version it is written in and the runtime version.

Linking libraries

An application that installs an LTO compiled library will link it at the building time just-in-time. The Linker , which does the linking, will generate code based on the declarations from the LTO compilation, and replace them with definitions that can be used by the application.

Unlike ngcc, which required analysis step, the linking process can be executed independently for each file thanks to Locality of LTO compilation, so it can work as a plugin in module resolution like webpack. In the Angular CLI build, it is implemented as a Babel plugin called AngularLinker.

Wrap-up

The new Ivy library compilation can be summarized as follows:

The library compilation is separated into two parts: before and after NPM release.
One is the LTO compile process that finishes the decorator analysis before publishing to NPM.
The other is the linking process, which completes the compilation of the library by generating code at application build time.

I hope this article will help you readers understand how new Ivy library compilation is designed, based on the differences between applications and libraries in compilation, and the issues of ngcc used today.

Angular: Using NgRx Store with Redux Toolkit 🚀

Suguru Inatomi — Wed, 16 Dec 2020 12:09:31 +0000

Original Post: https://blog.lacolaco.net/2020/12/angular-using-ngrx-with-redux-toolkit/

This article introduces the idea of combining NgRx Store, the de facto standard state management library for Angular applications, with the Redux Toolkit, a library from the Redux team.

I expect that this will eventually become the solid configuration for Angular applications.

What is the Redux Toolkit (RTK)?

If you are already familiar with the Redux Toolkit, you can find it in the following “NgRx Store with RTK” section.

The Redux Toolkit ( RTK ) is the official library of the Redux development team. It provides best practices that match real-world use cases to make it easier and more effective for anyone to use Redux. A major theme of RTK is the reduction of cumbersome boilerplate code that has frequently occurred in Redux in the past. You can get a good overview of this through the Redux Toolkit Basic Tutorial. It is recommended that you read through it first.

https://redux-toolkit.js.org/tutorials/basic-tutorial

The ability to create Actions, Action Creators, Reducers, etc. with creating functions is also effective in reducing the existing boilerplate, but the most important thing is the last createSlice function. Just by looking at the code sample, you can see that the API is quite different from the impression of Redux so far, and the amount of code can be reduced considerably.

https://redux-toolkit.js.org/tutorials/basic-tutorial#introducing-createslice

const counterSlice = createSlice({
  name: 'counter',
  initialState: 0,
  reducers: {
    increment: (state) => state + 1,
    decrement: (state) => state - 1,
  },
});

const store = configureStore({
  reducer: counterSlice.reducer,
});

document.getElementById('increment').addEventListener('click', () => {
  store.dispatch(counterSlice.actions.increment());
});

In the future, Redux will basically be based on this Slice. Most of the existing Redux logic should be able to be solved by createSlice(), unless you are using it in a very complex way.

This API is the standard approach for writing Redux logic. (https://redux-toolkit.js.org/api/createSlice)

The concept of Slice is a new one created by the Redux Toolkit, but its essence is not entirely new. Here is a detailed explanation of Slice.

The concept of Slice

“Slice” is an object that encapsulates the Reducer and Action Creators created under the namespace.

createSlice returns a “slice” object that contains the generated reducer function as a field named reducer, and the generated action creators inside an object called actions. (https://redux-toolkit.js.org/tutorials/basic-tutorial)

// Creating a slice
const counterSlice = createSlice({
  name: 'counter',
  initialState: 0,
  reducers: {
    increment: (state) => state + 1,
  },
});
// Auto-generated reducer and action creators
const { reducer, actions } = counterSlice;
actions.increment(); // => Action { type: 'counter/increment' }

If you are familiar with the Redux “ducks” pattern, you will feel a sense of déjà vu when you see Slice, which is the exact representation of the ducks pattern as a type of object. The ducks pattern can be easily implemented by simply exporting each property individually from the return value of createSlice().

Thanks to createSlice, we already have our action creators and the reducer right here in one file. All we have to do is export them separately, and our todos slice file now matches the common “ducks” pattern. (https://redux-toolkit.js.org/tutorials/intermediate-tutorial)

// ducks pattern exports
export const { increment } = counterSlice.actions;
export default counterSlice.reducer;

The reason why it is called “Slice” will become clearer when we apply multiple Slices to a single Store. To combine multiple Slices, we will continue to use the combineReducers function. The Slice is the combination of [name]: namedReducer in this combine step. Each slice is a thin layer of the whole reducer.

There have been various approaches to dividing the Reducer in this way, and the ducks pattern has been popular. It creates modules that are scoped by namespaces while ensuring atomic state updates through centralized state management infrastructure. The reason why RTK and createSlice() should be used is that it is easy and anyone can implement the scalable Redux best practices in the same way.

NgRx Store with RTK

Redux is a framework-agnostic library. But why NgRx Store is widely used for Angular app state management instead of plain Redux?

Because it’s easy to set up in Angular’s DI.
Because they want to manage state changes with RxJS (Observable)
Because they want to use TypeScript’s type checking
Because it requires less boilerplate code than plain Redux

RTK can also solve the needs of TypeScript-friendliness and simplicity of description, and it also has the sense of security of being a Redux official. So, by using NgRx Store with RTK, we can write state management logic that blends naturally into Angular applications while benefiting from the Redux ecosystem. This is the starting point of my idea, and I am confident that it will work.

`StoreModule.forFeature()` and Slice

In NgRx Store, you can create a “Feature State” by using StoreModule.forFeature() for lazy loading or simply for separation of concerns. For applications of a large size, it is common to modularize them into Feature States instead of managing everything in the Root State.

import counterReducer, { name as counterFeatureKey } from './state/counter';

@NgModule({
  imports: [StoreModule.forFeature(counterFeatureKey, counterReducer)],
})
export class CounterModule {}

To create a Feature State, you need a string that is the key to distinguish the Feature and a Reducer function corresponding to the Feature State. And as mentioned earlier, RTK’s Slice has the same information. In other words, Feature State and Slice are both APIs aimed at modularizing state management, and their essence is almost the same.

By the way, NgRx Store is a state management library for Angular, based on RxJS, but its core is strongly inspired by Redux.

Store is RxJS powered global state management for Angular applications, inspired by Redux. (https://ngrx.io/guide/store)

This is not only the idea but also the interface of Action and Reducer, the principle part of Redux, is the same. So the objects generated by RTK can be directly applied to NgRx Store. In other words, the key and Reducer required for the Feature State can be generated by Slice.

I will explain the implementation with a simple example. It is a small application, but it has everything you need to integrate NgRx Store with RTK.

0. Setup NgRx Store

First, we need to prepare StoreModule.forRoot() to make Store available to components and services. If it is fully modularized, there will be no reducer to pass to forRoot().

@NgModule({
  imports: [BrowserModule, StoreModule.forRoot({})],
  // ...
})
export class AppModule {}

1. Create a counter slice

The first thing to do is to create a Slice. Create counter/counter-slice.ts and use the createSlice() function to create a Slice object. That’s almost all the code for state management.

import { createSlice } from '@reduxjs/toolkit';

const counterSlice = createSlice({
  name: 'counter',
  initialState: {
    count: 0,
  },
  reducers: {
    increment: (state) => {
      state.count++;
    },
  },
});

2. Make a “ducks” module

Based on the Slice created in step 1, we will modularize the Slice according to the ducks pattern: default export for Reducer, named export for Action Creator and other objects. Using object destructuring, we can write like the following:

const {
  reducer,
  actions: { increment },
  name,
} = counterSlice;

export default counterSlice.reducer;
export { increment, name };

This is a preference, so if you don’t find the ducks pattern valuable, you can export the Slice object as is.

3.Setup `StoreModule.forFeature()`

We will use the object exported from counter-slice.ts to set the Feature State of NgRx. Just call StoreModule.forFeature() in counter.module.ts and pass the name and reducer of the Slice as follows:

import counterReducer, { name as counterFeatureKey } from './counter-slice';

@NgModule({
  imports: [StoreModule.forFeature(counterFeatureKey, counterReducer)],
  // ...
})
export class CounterModule {}

4. Creating a Feature selector

In the NgRx Store, it is common to use a Feature Selector to retrieve the Feature State from the Store. This time, counter-slice.ts itself will create and export a Feature Selector. The type of the Feature State managed by counterSlice can be retrieved using ReturnType<typeof reducer>, thanks to RTK’s strong type inference support.

export const selectFeature = createFeatureSelector<ReturnType<typeof reducer>>(
  name
);

5. Access to Feature State

Finally, refer to the Feature State from the component, dispatch an Action to update it, and you are done. The code in this area is not affected by the RTK.

import { createSelector, Store } from '@ngrx/store';
import * as counterSlice from './counter-slice';

@Component({
  selector: 'app-counter',
  template: `<button (click)="increment()">INCREMENT</button>:
    {{ counter$ | async }}`,
})
export class CounterComponent {
  constructor(private readonly store: Store<{}>) {}

  // Get state
  counter$ = this.store.select(
    createSelector(counterSlice.selectFeature, (state) => state.count)
  );

  increment() {
    // Update state
    this.store.dispatch(counterSlice.increment());
  }
}

Advantages and disadvantages

This is a brief summary of the advantages and disadvantages of using NgRx Store with RTK.

Advantage: minimized boilerplate

Compared to the bare Redux, utilities provided by NgRx such as createReducer and createAction simplify the description, while createSlice() reduces waste to the absolute minimum. It not only reduces the amount of code but also hides the combination of multiple APIs in just one createSlice(), which is very good in terms of ease of remembering how to use it.

// NgRx
import { createAction, createReducer } from '@ngrx/store';

export const increment = createAction('[Counter Component] Increment');
export const initialState = 0;

const _counterReducer = createReducer(
  initialState,
  on(increment, (state) => state + 1)
);

export function counterReducer(state, action) {
  return _counterReducer(state, action);
}


// Redux Toolkit
import { createSlice } from '@reduxjs/toolkit';

const counterSlice = createSlice({
  name: 'counter',
  initialState: 0,
  reducers: {
    increment: (state) => state + 1,
  },
});

Advantage: Redux Ecosystem

RTK will become a central part of the Redux ecosystem in the near future, and new projects derived from RTK are emerging. For example, the recently released RTK Query is an experimental library that automates the common Redux use case of fetching data and caching the response. RTK-based state management makes it easier to keep up with the evolution of the Redux ecosystem.

Disadvantage: Increased bundle size

The RTK comes with some middleware by default, so the bundle size should be larger than the plain NgRx Store. Tree-shaking will mitigate this, but the increment will not be zero.

Conclusion

I had the opportunity to introduce my idea on the interoperability between NgRx Store and RTK.

I put up an issue on the NgRx GitHub repository suggesting how to improve interoperability with RTK, and the NgRx maintainer was very positive, and also Mark Erikson, the Redux maintainer, showed up and welcomed it.

https://github.com/ngrx/platform/issues/2809

// Detect dark theme var iframe = document.getElementById('tweet-1336804656777932803-373'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1336804656777932803&theme=dark" }

Since the RTK, the Redux ecosystem seems to be gaining momentum in spreading best practices that match real-world use cases. And I found out that there is an option to delegate the core of state management to the Redux official. I think the role of NgRx in combination with RTK will be to connect Redux with Angular’s DI system and reactive programming with RxJS as a bridge. And I believe that this division of responsibilities will become more important in the future.

The implementation example presented here is just one idea at the moment, and if you can find a better interoperable implementation pattern, I would love to see NgRx Store + RTK made by others. I’m looking forward to your feedback.

See you.

Angular: Eliminate Render Blocking Requests の概要

Suguru Inatomi — Thu, 01 Oct 2020 00:10:06 +0000

Originally published on blog.lacolaco.net.

この記事では Angular CLI チームで現在進行中の “Eliminate Render Blocking Requests” というプロジェクトについてその内容を解説する。一次ソースは以下のリンク先を参照されたし。

概要

このプロジェクトは Angular アプリケーションが依存する CSS について、 Render-Blocking な HTTP リクエストを無くそうというものである。 Render-Blocking なリソースの除去については web.dev の記事を参考にするとよい。

Eliminate render-blocking resources

最初のレンダリングに必要な CSS の読み込み時間がなくなることで First Contentful Paint（FCP）のパフォーマンスが改善される見込みだ。

Angular CLI チームが RFC（Request For Comments）で提案したのは次のような手法である。

CSS ファイルの読み込みの非同期化
Angular Universal SSR や Pre-rendering、App-Shell、通常のクライアントサイドレンダリングでのクリティカル CSS のインライン化
Google Fonts と Icons のインライン化

これらを Angular CLI で特別な設定無しに利用できるようにすることを目的としている。

背景

ng build コマンドのビルドに使われる styles の CSS ファイルは基本的にリセット CSS や Theming など、ページ表示の最初に読み込まれることが期待されている。しかし CSS は styles.css のような形でバンドルされ、 <link>タグで読み込むことになるため、この styles.css が肥大化するとページの First Contentful Paint（FCP）が遅くなる原因になる。とはいえ styles.css の内容をすべてインライン化するのは HTML ファイルのペイロードサイズを肥大化させてしまう。

そこで、本当にクリティカルな CSS だけをインライン化し、残りの部分を非同期化することで FCP を改善しようというのが今回の趣旨である。

解決案

これらの手法は Angular CLI に合理的な形で組み込めるかどうかはまだ保証できないが、現時点でのアイデアとして提案されているものであり、確定事項ではない。

CSS の非同期読み込み

バンドルされた styles.css が初期レンダリングに必要のないため CSS の読み込みを待たずにレンダリングを始めてよいことをブラウザに伝える。具体的には <link> タグの media 属性を使い、印刷などの特殊なユースケースを除いた通常のユースケースでは読み込みを非同期化する。

Before

<link rel="stylesheet" href="styles.css" />

After

<link
  rel="stylesheet"
  href="styles.css"
  media="print"
  onload="this.media='all'"
/>
<noscript><link rel="stylesheet" href="styles.css" /></noscript>

参考: レンダリングブロック CSS | Web | Google Developers

CSS Files Budget

CSS のダウンロードやパースの時間を短縮するため、ファイルサイズに関する新たな Budget を追加する。実際には参照されないデッドコードの除去や、グローバル CSS ではなく適切なコンポーネントのスタイルへの移動などを促進する。

anyStyle: 外部 CSS ファイル個別のサイズ
allStyle: すべての外部 CSS ファイルの累計サイズ

すでに存在するanyComponentSyle はコンポーネント CSS のファイルサイズを対象としているので全く別物である。

Google Fonts と Icons のインライン化

https://fonts.googleapis.com/ から最初にダウンロードするフォント読み込みの CSS をインライン化することで HTTP リクエストのラウンドトリップを削減する。これまでは CSS の読み込みのあとに woff などのフォントファイルの読み込みが行われていたが、フォントファイルの読み込みだけになる。また、Angular CLI が参照する browserslist の設定に基づいて最適なフォントフォーマットの決定も自動的に行われる。

Before

<link
  rel="stylesheet"
  href="https://fonts.googleapis.com/icon?family=Material+Icons"
/>

After

<style>
  @font-face {
    font-family: 'Material Icons';
    font-style: normal;
    font-weight: 400;
    src: url(https://fonts.gstatic.com/s/materialicons/v55/flUhRq6tzZclQEJ-Vdg-IuiaDsNcIhQ8tQ.woff2)
      format('woff2');
  }

  .material-icons {
    font-family: 'Material Icons';
    font-weight: normal;
    font-style: normal;
    font-size: 24px;
    line-height: 1;
    letter-spacing: normal;
    text-transform: none;
    display: inline-block;
    white-space: nowrap;
    word-wrap: normal;
    direction: ltr;
  }
</style>

クリティカル CSS の抽出

Render-Blocking な CSS だけをインライン化するためには CSS を解析してその部分だけを抽出する必要がある。これをすでに実現しているプロジェクトとして、penthouseやcritters、criticalなどがある。これらはアプリケーションを一度レンダリングし、そこで参照されたクリティカル CSS を抽出する方法をとっている。

Google Chrome チームが開発している critters は抽出のためのレンダリングにヘッドレスブラウザではなく JSDOM を用いており、ビルド時だけでなくランタイムで動作させる選択肢としては上述のツールの中で最適であると考えられる。ただし、critters は viewport を予測せず、ドキュメントに読み込まれたすべての CSS をインライン化してしまうトレードオフがある。

また、Angular アプリケーションのユースケースにおいてそれぞれの課題を挙げている。

Angular Universal (SSR)

critters は webpack プラグインであるため、Node.js サーバー上で動的にビルドする Angular Universal は利用できない。したがって、Universal を考慮すれば critters のコア機能だけを Node.js 向けに切り出したものが必要になるだろう。うまく実現できれば、Universal でビルドした HTML の中にクリティカル CSS をインライン化してクライアントに返すことができる。

App-Shell / Pre-rendering

Angular CLI のビルド時にあらかじめ HTML をレンダリングする App-Shell や Universal Pre-rendering のユースケースについては、critters の基本的なアプローチで解決できる。

Client Side Rendering （CSR）

クライアントサイドレンダリングのアプリケーションは、Node.js 環境で実行できないため critters のようなツールでのクリティカル CSS 抽出ができない。しかし Angular コンテキストではないカスタムの CSS 読み込みは index.html で記述されることが多いため、ビルド時にこれらを抽出してインライン化することでこのケースをカバーする。

代替案

以下のアイデアは現時点では有用性が低い、実現可能性が低いなどの理由で採用される見込みの低いものである。

明示的なクリティカル CSS 定義

インライン化されるべきクリティカル CSS を開発者がアノテーションし、postcss-critical-splitのようなツールで抽出するアプローチ。このアプローチはその CSS がクリティカルであるかを開発者が判断しなければならないという問題と、サードパーティ CSS にはアノテーションできないという欠点があるため却下された。

/* critical:start */
header {
  background-color: #1d1d1d;
  font-size: 2em;
}

.aside {
  text-decoration: underline;
}
/* critical:end */

ヘッドレスブラウザによるクリティカル CSS 抽出

Penthouse はヘッドレス Chrome を使ってレンダリングしてクリティカル CSS を抽出するため、 Node.js で実行できない CSR のアプリケーションにも適用できる点で優れている。

ただしこのアプローチはランタイムで実行しなければならない Angular Universal のユースケースでパフォーマンスを落とすため却下された。

ルートコンポーネントでのグローバル CSS 読み込み

いわゆる AppComponent の styles を使ってグローバル CSS を読み込んでしまうことでコンポーネント CSS として Render-Blocking しない形でインライン化するアプローチ。

これは App-Shell や Pre-rendering のユースケースにおいて index.html が styles.css の内容をすべて含み肥大化してしまう欠点がある。

DNS-Prefetch と Preconnect Hints

Google Fonts と Icons の読み込みについて、DNS-Prefetch と Preconnect Hints を活用するアプローチ。欠点は特に無いが CSS のインライン化のほうがより効果的であると考えている。

RFC のフィードバック

RFC を通して集まったフィードバックのまとめは以下の通り。

この機能はデフォルトで有効であり、オプトアウト可能であるべき
新しい Size Budget は新プロジェクト、既存プロジェクトの両方に追加されるべき
CSS ファイルの Budget の追加にあたり、非利用 CSS の除去の手段も一緒に提供されることが望まれている

まとめ

リリース時期はまだ未定であるが、Angular アプリケーションのパフォーマンス改善のための大きなプロジェクトである。 v10 で導入された CommonJS インポート時の警告といい、Angular 特有のパフォーマンスというよりは web.dev で取り上げられるようなベストプラクティス的なパフォーマンス改善のアプローチを、Angular CLI のデフォルト機能としてサポートする取り組みに力が入っているようにも見える。

How CommonJS is making your bundles larger

Eliminate Render-Blocking Requests についてはゼロコンフィグ、あるいはほぼ設定不要で使えるべきであるという姿勢が強く見られるため、完成には時間がかかりそうではあるがぜひ期待したい。

Angular: Lightweight Injection Tokenという新しいテクニック

Suguru Inatomi — Wed, 29 Jul 2020 04:57:17 +0000

最近Angularチームが発見し、Angularライブラリの実装におけるパターンとして普及させようとしているのが、 Lightweight Injection Token というテクニックだ。これはこれまで不可能だった コンポーネント(ディレクティブ)のTree-Shaking を可能にする。本稿ではこの新しいテクニックの概要、そして生まれた経緯や深く知るための参考リンクをまとめる。

なお、Lightweight Injection Tokenについては公式ドキュメントでも解説される予定であるため、そちらを参照すればいい部分は省略する。

Angular - Optimizing client app size with lightweight injection tokens

Lightweight Injection Tokenの概要

ひとことでいえば、「オプショナルな機能に関連するInjection Tokenとして代替の軽量トークンを使う」ということである。AngularのDIを深く理解していればこれだけでピンと来るかもしれないが、具体例から概要をつかもう。

あるAngularライブラリが、次のような使い方ができる <lib-card> コンポーネントを提供している。

<lib-card>
  Hello World!
</lib-card>

このコンポーネントは、Contentとして <lib-card-header> コンポーネントを配置すると、カードのヘッダーとして取り扱う オプショナル な機能があることをイメージしよう。

<lib-card>
  <lib-card-header>Greeting Card</lib-card-header>
  Hello World!
</lib-card>

ライブラリ側はこのような使い方ができるコンポーネントを実装するとおおよそ次のようになるだろう。 @ContentChild() を使って CardHeaderComponent の参照を得る。ただしこのヘッダーを置くかどうかはユーザー次第なので、 CardHeaderComponent|null という形でnullを許容することになる。

@Component({
  selector: 'lib-card-header',
  ...,
})
class CardHeaderComponent {}

@Component({
  selector: 'lib-card',
  ...,
})
class CardComponent {
  @ContentChild(CardHeaderComponent)
  header: CardHeaderComponent|null = null;
}

ここで問題になるのが、 CardComponent から CardHeaderComponent への参照の持ち方である。 @ContentChild(CardHeaderComponent) と header: CardHeaderComponent|null の2箇所で参照を持っているが、この2つは性質が異なる。

後者の header: CardHeaderComponent|null は、型としての参照である。この参照はTypeScriptのコンパイル時型チェックにのみ用いられ、コンパイル後のJavaScriptには残らないため問題にならない。

問題は前者の @ContentChild(CardHeaderComponent) だ。これは値としての参照であり、 CardHeaderComponent というクラスオブジェクトそのものを参照している。それが直接 @ContentChild() デコレーターに渡されているのだから、 ユーザーがヘッダーを使おうが使わまいが、この参照は実行時に残る 。

@ViewChild() や @ContentChild() の走査条件として使われるコンポーネント/ディレクティブのクラス参照はどうしてもTree-Shakingできず、これがAngularライブラリを利用したときの バンドルサイズの肥大化の原因 となる。

これを解決するためのアプローチが、Lightweight Injection Tokenだ。上記の例で @ContentChild() デコレーターに渡していたクラスを、次のように軽量なオブジェクトを利用したInjection Tokenに置き換える。

// Lightweight Injection Token
abstract class CardHeaderToken {}

@Component({
  selector: 'lib-card-header',
  providers: [
    {provide: CardHeaderToken, useExisting: CardHeaderComponent}
  ]
  ...,
})
class CardHeaderComponent extends CardHeaderToken {}

@Component({
  selector: 'lib-card',
  ...,
})
class CardComponent {
  @ContentChild(CardHeaderToken) header: CardHeaderToken|null = null;
}

まず CardHeaderToken 抽象クラスを作成し、 CardHeaderComponent をその具象クラスとする。そしてコンポーネントプロバイダーで CardHeaderToken に対して自身のクラスオブジェクトを提供する。 CardComponent ではトークンを @ContentChild()デコレーターの走査条件とする。

これにより、 CardComponent から直接の CardHeaderComponent への参照はなくなり、ライブラリのユーザーが <lib-card-header> コンポーネントを呼び出したときだけ CardHeaderToken に対して CardHeaderComponent クラスのインスタンスが提供されることになる。

@ContentChild() や @ViewChild() の引数としてDIトークンを渡せるようになるのがバージョン 10.1.0からなので、このアプローチが取れるのは バージョン 10.1.0以降 になる（ as any で突破する手法はあるが）。

feat(core): support injection token as predicate in queries (#37506) · angular/angular@97dc85b

なぜ今なのか、これまでの経緯

この問題は昔からずっと存在したが、実はバージョン8まではそれほど重大な問題ではなかった。なぜかというとバージョン8以前、つまりIvy以前 (ViewEngine, VE) はAOTコンパイルによってテンプレートコンパイルされた結果の生成コードが、もとのコンポーネントとは別のクラス実体をもっていたからだ。

ViewEngineでは CardComponent クラスのデコレーターとそのメタデータをもとに CardComponentNgFactory クラスが生成される。そして、JavaScriptとしてコードサイズが大きいのはほとんどの場合NgFactory側である。

つまり上記の例でいえば、たとえ CardComponentNgFactory クラスが CardHeaderComponent への参照を持っていたとしても、CardHeaderComponent そのものが大きくないために問題にならなかったのだ。サイズが大きいのは CardHeaderComponenNgFactory のほうで、NgFactoryはテンプレート中で <lib-card-header> を使わない限り参照されないため、不完全ではあるがTree-ShakingできていたのがViewEngine方式だった。

バージョン9からデフォルトになったIvy方式のAOTコンパイルは、生成コードを もとのクラスの静的フィールドとして合成する 。よって AOTコンパイルすると CardHeaderComponent そのもののサイズが大きくなり、 CardComponent に巻き込まれて一緒にバンドルされるサイズが顕著に大きくなる。いままで行なわれていた生成コードのTree-ShakingがIvyによりなくなってしまった。

つまり、Lightweight Injection TokenはViewEngine時代には顕在化していなかったがIvyによってクリティカルになった問題を解決するために編み出された、 Ivy時代のAngualrライブラリ実装パターン である。

もっともポピュラーなAngularのコンポーネントライブラリであるAngular Materialではバージョン9リリース時からバンドルサイズの増加が報告されており、その解消の過程でAngularチームが辿り着いた答えである。現在Angular ComponentsチームはAngular Materialの各コンポーネントをLightweight Injection Tokenパターンに置き換える作業を進めている。

Increased initial main.js bundle size in v9 - mainly due to @angular/material packages · Issue #19610 · angular/components

Use light-weight injection pattern for optimized tree-shaking/bundle size · Issue #19576 · angular/components

コンポーネント以外のLightweight Injection Token

ところで、 @ContentChild() などの走査条件でなくとも、通常のDIの中でもオプショナルなものについてはLightweight Injection Tokenパターンを使うべきである。 @Optional() を使っていてもそのトークンの参照は残るためTree-Shakingはできない。コンストラクタDIでは型注釈部分にしか参照がないためコンパイルすれば消えそうに見えるが、コンストラクタ引数の型注釈はAOTコンパイル時に自動的に @Inject() デコレーターに変換されるため、実体参照をもつのである。つまりこれも @ContentChild() と全く同じ構造であり、同じ問題をもちうる。ライブラリ作者であればオプショナルなプロバイダーのトークンは可能な限り軽量にしておくべきだろう。

class MyComponent {
  constructor(@Optional() srv: OptionalService) {}
}

// Same
class MyComponent {
  constructor(@Optional() @Inject(OptionalService) srv: OptionalService) {}
}

ちなみにコンポーネントのLightweight Injection Tokenとして InjectionToken オブジェクトを使うこともできるはずだ。公式ドキュメントでは抽象クラスの例が紹介されているが、どちらが定着するかは今後のコミュニティでの受け入れられ方次第だろう。ただ、トークンの抽象クラスとコンポーネントクラスを継承関係にするとそのままコンポーネントのAPI定義として利用もできるため、おそらくは抽象クラスのほうが便利な場面は多そうだ。

const CardHeaderToken
  = new InjectionToken<CardHeaderComponent>("CardHeaderComponent");

https://angular.io/guide/dependency-injection-providers#non-class-dependencies

参考リンク

以下に参考リンクをまとめる。

Misko HeveryによるDesign Doc https://hackmd.io/@mhevery/SyqDjUlrU
公式ドキュメントへの追加PR https://github.com/angular/angular/pull/36144
Angular MaterialのIssue https://github.com/angular/components/issues/19576

Angular Elements: Composable Definition Pattern

Suguru Inatomi — Wed, 22 Jul 2020 01:59:46 +0000

Assuming a situation we have…

An Angular component library project, Lib1Module
An Angular Elements library project, Lib1ElementsModule
An Angular Elements library project, Lib2ElementsModule which uses Lib1ElementsModule

It can be achieved with loading scripts of both Lib1 and Lib2 separately. But composing multiple Angular Elements definition brings some benefits.

Unified Angular bootstrapping (better performance)
Single <script> tag in HTML (free from loading order problem)

Creating `Lib1ElementsModule`

import { createCustomElement } from '@angular/elements';

export function defineCustomElements(injector: Injector) {
  customElements.define(
    'lib1-button-element',
    createCustomElement(Lib1ButtonComponent, { injector })
  );
}

@NgModule({
  imports: [Lib1Module],
  // `entryComponents` is not needed if Ivy is enabled
  entryComponents: [Lib1ButtonComponent],
})
export class Lib1ElementsModule {
  constructor(private readonly injector: Injector) {}

  ngDoBootstrap() {
    defineCustomElements(this.injector);
  }
}

To use Lib1ElementsModule , bootstrap it directly. Then ngDoBootstrap() method will be called.

// main.elements.ts
platformBrowserDynamic().bootstrapModule(Lib1ElementsModule);

Creating `Lib2ElementsModule`

Lib2ElementsModule enables both Lib1 and Lib2 Angular Elements by composition.

import { createCustomElement } from '@angular/elements';
import {
  Lib1ElementsModule,
  defineCustomElements as defineLib1Elements,
} from 'lib1';

export function defineCustomElements(injector: Injector) {
  customElements.define(
    'lib2-card-element',
    createCustomElement(Lib2CardComponent, { injector })
  );
}

@NgModule({
  imports: [Lib2Module, Lib1ElementsModule],
  // `entryComponents` is not needed if Ivy is enabled
  entryComponents: [Lib2CardComponent],
})
export class Lib2ElementsModule {
  constructor(private readonly injector: Injector) {}

  ngDoBootstrap() {
    // Compose definition
    defineLib1Elements(this.injector);
    defineCustomElements(this.injector);
  }
}

Initial Null Problem of AsyncPipe and async data-binding

Suguru Inatomi — Wed, 19 Feb 2020 00:54:03 +0000

Original Post: https://blog.lacolaco.net/2020/02/async-pipe-initial-null-problem-en/

Angular's AsyncPipe is a useful feature for template binding of asynchronous data, but it has a big problem since the beginning. That is the "Initial Null Problem".
This article describes the Initial Null Problem of AsyncPipe and its root cause, and discusses new asynchronous data-binding to solve that.

I recommend you to see also this great article:

Handling Observables with Structural Directives in Angular - DEV Community 👩‍💻👨‍💻

How AsyncPipe works

AsyncPipe is now always used to create general Angular applications. It is often used to subscribe to Observable data and bind its snapshot to a template.
The basic usage is as follows.

@Component({
  selector: "app-root",
  template: `
    <div *ngIf="source$ | async as state">
      {{ state.count }}
    </div>
  `,
  styleUrls: ["./app.component.css"]
})
export class AppComponent {
  source$ = interval(1000).pipe(map(i => ({ count: i })));
}

So, how does AsyncPipe bind the value that source$ streams to a template and render it? Take a look at Implementation of AsyncPipe.

AsyncPipe has a lot of asynchronous data abstraction code that can handle both Promise and Observable, but the essential code is the following code. Like any other Pipe, it implements the transform() method.

  transform(obj: Observable<any>|Promise<any>|null|undefined): any {
    if (!this._obj) {
      if (obj) {
        this._subscribe(obj);
      }
      this._latestReturnedValue = this._latestValue;
      return this._latestValue;
    }

    if (obj !== this._obj) {
      this._dispose();
      return this.transform(obj as any);
    }

    if (ɵlooseIdentical(this._latestValue, this._latestReturnedValue)) {
      return this._latestReturnedValue;
    }

    this._latestReturnedValue = this._latestValue;
    return WrappedValue.wrap(this._latestValue);
  }

Let's look at the code from the top. The first if (!this._obj) is the condition when Observable is passed to AsyncPipe for the first time, that is, the initialization process. If this._obj doesn't exist and obj does, the pipe subscribes obj. obj corresponds to source$ in the example. The Observable passed to AsyncPipe is executed subscribe() here.

The next if statement is for when an Observable has changed from the one you are subscribing. It disposes the current subscription and starts resubscribing.

And the rest of the code is for returning the latest value this._latestValue from the subscribed Observable. The returned value will be the value actually used to render the template.

What you can see here is that AsyncPipe returns the cached this._latestValue when thetransform()method is called.
This can also be seen in AsyncPipe's _subscribe() and this._updateLatestValue() methods. When the value flows into the asynchronous data subscribed by the _subscribe() method, markForCheck() of ChangeDetectorRef is called in the callback. It causes the next transform() call.

  private _subscribe(obj: Observable<any>|Promise<any>|EventEmitter<any>): void {
    this._obj = obj;
    this._strategy = this._selectStrategy(obj);
    this._subscription = this._strategy.createSubscription(
        obj, (value: Object) => this._updateLatestValue(obj, value));
  }
  ...
  private _updateLatestValue(async: any, value: Object): void {
    if (async === this._obj) {
      this._latestValue = value;
      this._ref.markForCheck();
    }
  }

In other words, AsyncPipe renders templates using the following mechanism.

Pipe's transform() is called in Change Detection
Start subscribing to the passed Observable
Return this._latestValue at the time transform()is called
When Observable flows new data, update this._latestValue and trigger Change Detection (back to 1)

transform() must return a synchronous value, because the template can only render synchronous values. It can only return a cached snapshot at the time transform() is called.

A solid understanding of this should raise a question. That is, "at the start of the subscription, can't the transform() return a value?" And that is the biggest problem that AsyncPipe has, the "Initial Null Problem".

Initial Null Problem

Since this._latestValue is set by Observable's subscription callback, the value has never been set at the time of transform() call. However, transform() must return some value, so it returns a default value.
Let's look again at the beginning of AsyncPipe's transform().

    if (!this._obj) {
      if (obj) {
        this._subscribe(obj);
      }
      this._latestReturnedValue = this._latestValue;
      return this._latestValue;
    }

this._latestValue used in the last two lines has never been set, so the initial value of this field will be used. Its value is null.

export class AsyncPipe implements OnDestroy, PipeTransform {
  private _latestValue: any = null;
  private _latestReturnedValue: any = null;

In other words, AsyncPipe always returns null once before flowing the first value. Even if the original Observable is Observable<State>, it becomes State | null through AsyncPipe. This is a problem I call " Initial Null Problem".

While this problem seems serious, it has been automatically avoided in many cases. This is because *ngIf and *ngFor, which are often used with AsyncPipe, ignore the null returned from AsyncPipe.

In the following template, the value returned by source$ | async is evaluated by the NgIf directive, and if it is Truthy, it will be rendered, so if it is null, it will not go inside *ngIf.

<div *ngIf="source$ | async as state">
  {{ state.count }}
</div>

Similarly, in the following template, the value returned by source$ | async is evaluated by the NgFor directive and ignored if it is Falsey, so if it is null, it will not be inside *ngFor.

<div *ngFor="let item of source$ | async">
  {{ item }}
</div>

Through null-safe directives such as *ngIf and *ngFor, the Initial Null Problem does not affect the application. The problem is otherwise, that is, passing values directly to the child component's Input via AsyncPipe.
In the following cases, the child component should define a prop Input type, but you have to consider the possibility of passing null to it. If prop is a getter or setter, you can easily imagine a runtime error when trying to access the value.

<child [prop]="source$ | async"></child>

So far, one simple best practice can be said.
AsyncPipe should always be used through a null-safe guard like NgIf or NgFor.

Replace AsyncPipe

From here, I will explore the new asynchronous data-binding that can replace AsyncPipe which has the above-mentioned problem.

Why AsyncPipe returns null is Pipe needs to return a synchronous value. The only way to solve the Initial Null Problem is to stop using Pipe for async data.

So I tried using a directive. I think an approach that accepts an input and a template and renders the template under the control of the directive, is the best replacement for AsyncPipe.

So I implemented the *rxSubscribe directive. The sample that actually works is here. It subscribe an Observable with a structural directive as follows:

<div *rxSubscribe="source$; let state">
  {{ state.count }}
</div>

The directive is implemented as follows. What this directive does is

Subscribe an Observable received by rxSubscribe Input.
When the Observable value flows, embed (render) the template for the first time
When the value after the second time flows, update the context and call markForCheck()

https://github.com/lacolaco/ngivy-rx-subscribe-directive/blob/master/src/app/rx-subscribe.directive.ts

@Directive({
  selector: "[rxSubscribe]"
})
export class RxSubscribeDirective<T> implements OnInit, OnDestroy {
  constructor(
    private vcRef: ViewContainerRef,
    private templateRef: TemplateRef<RxSubscribeFromContext<T>>
  ) {}
  @Input("rxSubscribe")
  source$: Observable<T>;

  ngOnInit() {
    let viewRef: EmbeddedViewRef<RxSubscribeFromContext<T>>;
    this.source$.pipe(takeUntil(this.onDestroy$)).subscribe(source => {
      if (!viewRef) {
        viewRef = this.vcRef.createEmbeddedView(this.templateRef, {
          $implicit: source
        });
      } else {
        viewRef.context.$implicit = source;
        viewRef.markForCheck();
      }
    });
  }
}

With this approach, the template is not rendered until the value first flows, and re-rendering can be triggered only when the value flows. It solves the Initial Null Problem, and is also CPU-friendly because re-rendering is limited only when necessary.

By the way, the type of state in let stateis inferred from the type of source$ exactly if Ivy of Angular v9 or later, and if strictTemplates flag is enabled. When you make a mistake use of state, AOT compiler throws an error.

<div *rxSubscribe="source$; let state">
  {{ state.foo }}  <!-- compile error: state doesn't have `foo` -->
</div>

AsyncPipe could always only infer or null due to the Initial Null Problem, but the structure directive approach can infer the context type exactly from Observable<T>.

I've published this *rxSubscribe directive as the npm package @soundng/rx-subscribe.

Conclusion

AsyncPipe has Initial Null Problem
Guarding with NgIf or NgFor can avoid the initial null
Pipe has limitations in handling asynchronous data
Structural directive approach can solve AsyncPipe problem
Feedback welcome to @soundng/rx-subscribe

AngularでWeb Bundlesを試す

Suguru Inatomi — Wed, 25 Dec 2019 04:48:53 +0000

Angularアドベントカレンダー #2の24日目代打記事です。

Web Bundlesとは、現在標準化が検討されている新しいWebの仕様です。Webページとそれに紐づくサブリソースをひとつのバンドルとしてパッケージ化することができます。

この記事ではWeb Bundlesを手元のAngularアプリケーションで試してみたい人向けの手順を紹介します。

CLI Builderのインストール

lacolaco/ngx-web-bundlesというパッケージで、Angular CLI向けのBuilderを作っています。
次のコマンドを実行するだけで、Web Bundleをビルドする準備が整います。

$ ng add @lacolaco/ngx-web-bundle

インストールできたら、任意のプロジェクトでgen-bundleコマンドを実行します。

$ ng run <project name>:gen-bundle

ビルドが終わるとindex.htmlが出力されるdistディレクトリと同じ階層に out.wbn というファイルが生成されているはずです。このファイルをGoogle ChromeのCanary版で Web Bundlesを有効にしてから開くと、バンドルを展開できるはずです。

How it works

ngx-web-bundleがやっているのは２つのことです。

ng add されたときに angular.json を更新し、 gen-bundleコマンドを定義する
gen-bundleコマンドが実行されたときに処理する

ng-add時の動き

ng-add時に動くのは次のngAdd関数です。

https://github.com/lacolaco/ngx-web-bundles/blob/master/schematics/ng-add/index.ts#L15

やっていることは次の2つです。

対象とするプロジェクトを特定する
プロジェクトの architects に gen-bundleを追加する

`gen-bundle`時の動き

gen-bundleコマンドで動くのは次のbuild関数です。

https://github.com/lacolaco/ngx-web-bundles/blob/master/index.ts#L51

やっていることは次の3つです。

executeBrowserBuilder を使って、アプリケーションのビルドをおこなう（ng buildと同じ処理を実行する）
ビルド後の生成物を wbn パッケージを使ってバンドル化する
アプリケーションの生成物を同じ場所にバンドルを出力する

バンドル化の処理は次の関数に記述されています。特別に配慮が必要なのはindex.htmlだけで、それ以外はファイルごとに同じ処理をしています。

https://github.com/lacolaco/ngx-web-bundles/blob/master/index.ts#L24

ひとつひとつのやっていることはシンプルです。それらを組み合わせてルールに従って配置すれば簡単にAngular CLI経由で動かせるスクリプトを作成できます。

Takeaways

AngularでWeb Bundlesを試すなら @lacolaco/ngx-web-bundle をどうぞ
自作のスクリプトをng addやng runに対応させるのは意外に簡単です
- デバッグはちょっと面倒です
Web Bundlesについては web.dev/web-bundles/ を参照してください

Angularの追いかけ方

Suguru Inatomi — Tue, 24 Dec 2019 15:00:49 +0000

Angular #2 Advent Calendar 2019の25日目の記事です。

アドベントカレンダー2枚が埋まるほど日本でのAngularの熱が高まっていることがAngularのGDEとしてとても嬉しいです！
この記事ではAngularについてもっと深く知りたい、学びたいと思っている方々向けに、私が普段からウォッチしている信頼できるリソースを紹介します。

Twitter

Angular（@angular）

まずはもちろん公式アカウントです。公式アナウンスは基本的にこのアカウントから発信されます。

@stephenfluin/Angular GDEs

Angular GDEがまとめられたTwitterリストです。

Stephen Fluin（@stephenfluin）

Stephen FluinはAngularチームのDeveloper Advocateです。公式ブログの記事の執筆もおこなっています。彼の個人ブログでもAngularのテクニックなどを投稿しています。

Minko Gechev（@mgechev）

Minko GechevはAngularチームの開発者です。ツール周りやパフォーマンス改善に役立つTipsをよくツイートしています。ちなみに web.dev/angular の執筆はほとんどMinkoによるものです。

Brandon 👨🏿‍💻✍🏿🏀（@brandontroberts）
Mike Ryan（@MikeRyanDev）
Tim Deschryver（@tim_deschryver）

NgRxのメンテナーたちです

Michael Rx Hladky（@Michael_Hladky）

AngularとRxJSのインテグレーションに興味がある方はぜひMichael Hladkyをフォローするとよいでしょう。刺激的な記事やデモなどを時折公開してくれます。

Mike Hartington（@mhartington）

Ionicチームの開発者です。Ionicのことを知りたければMikeに質問すれば快く答えてくれるでしょう。

他にもたくさんフォローしてほしいアカウントはあるのですがキリがないので、ここに挙げた彼らのリツイートなどから見つけていくといいでしょう。

Blog

Angular Blog

公式ブログです。まずはここをウォッチしましょう。

https://dev.to/angular

Angular GDEを中心に信頼できる人たちの記事が集まるdev toのorganizationです。いろんなジャンルやレベルの記事が読めます

ANGULAR INDEPTH

Angular中上級者なら必読のブログです。決して初心者向けではない濃い記事ばかりが投稿されています。

Blogs | juri.dev

Angular GDEのJuri Strumpflohnerの個人ブログです。役に立つ記事がよく投稿されるのでぜひ読んでもらいたいです。

Blog - softwarearchitekt.at

Angular GDEのManfred Steyerのブログです。
ドメイン駆動設計などAngularアプリケーションのアーキテクチャに関する話題が多いので設計に興味があればぜひ読んでもらいたいです。サイトはドイツ語ですがだいたいの記事は英語で書かれてるので大丈夫です。

Netanel Basal – Netanel Basal

状態管理ライブラリのAkitaの作者でもあるNetanel Basalのブログです。ちょっとニッチな機能の使い方など、中級者におすすめの記事がたくさんあります。

Change Log

angular/angular

angular/angular-cli

angular/components

Angularのリポジトリの更新を追うならCHANGELOGやリリースを見るのがよいです。

Podcast

AngularAir - YouTube

ほぼ隔週で更新されているビデオpodcastです。Angular GDEのJustin Schwartzenbergerが主催していて、役に立つネタもあれば実験的なネタもあり面白いです。

年末年始、ぜひAngularを深く学ぶ時間にしてもらえれば幸いです。

Perspective of Angular in 2020

Suguru Inatomi — Tue, 24 Dec 2019 15:00:16 +0000

Angular Advent Calendar 2019の25日目の記事です。

この記事は GDG TokyoのDevFest 2019で発表した内容から抜粋、加筆したものです。
2019年も終わりということで、発表では今年一年のAngularの動きを振り返り、来年以降の展望についてまとめました。
この記事では振り返り部分は割愛し、2020年以降のAngularのロードマップについてのみ触れることにします。
全篇をご所望の場合はスライドを直接参照してください。

bit.ly/2Y5ZfJx

Roadmap in 2020

2020年の間にはv9.0からv11.xまでのリリースが行われる予定です。半年に一度のメジャーバージョンアップは今後も継続されます。

v9.0では次のような大きな変更があります。

Ivyのデフォルト有効化
CDK Clipboard APIの提供開始
CDK Testing Harnessの提供開始
@angular/{youtube-player, google-maps} パッケージの提供開始
テンプレート型チェックの厳密化オプション提供開始

Ivyへの移行スケジュール

v9.0では、すべてのアプリケーションでIvyモードでのAoTコンパイルがデフォルト有効になります。

今後v10.xまではオプトアウトの手段が用意されますが、v11.0を持ってオプトアウトできなくなります。11.0がリリースされる予定の2020年末には、すべてのAngularアプリケーションがIvyによるコンパイルをおこなっていることを目標にしています。

CDKの新しいAPI

Clipboard APIは文字列をクリップボードにコピーできるものです。テンプレート内で使えるディレクティブ形式のAPIと、クラス内で使えるサービス形式のAPIの両方が提供されています。

コンポーネントのテストをサポートするための ComponentHarness APIも新しく提供されます。 ComponentHarness を使うことで、コンポーネントのテストをメンテナンスしやすく記述できます。

テストしたいコンポーネントに対応するHarnessを定義し、そのHarnessに対するテストを書くことで、テストではコンポーネントの実装の詳細に依存せずに宣言的なテストを書けます。同時にHarnessの実装では DebugElement や ComponentFixture などのAPIが使いやすい形に隠蔽されています。Angular Materialのソースコードでは、すべてのコンポーネントがHarnessによるテストに切り替えられています。

Angular official components

Angular開発チームによる公式コンポーネントライブラリが新たに提供されます。

v9.0時点ではYouTubeプレイヤーを表示する @angular/youtube-player パッケージと、 Googleマップを表示する @angular/google-maps パッケージが提供されます。

Strict Template Type-Checking

Ivyコンパイルの有効化によって、テンプレートの隅々まで型チェックできるようになります。しかし後方互換性のためにv9.0においては厳密なテンプレート型チェックはオプションで提供されます。

tsconfig.json の angularCompilerOptions で strictTemplates フラグを有効にすると、TypeScriptの strictモードに近い厳密さでテンプレート型チェックがおこなわれます。

代表的なものでは、イベントハンドラーの $event 変数の型チェック、Inputの型チェック、コンポーネントメソッドの呼び出し型チェックなどが厳密になります。

Imagine the Future

v9.0以降のAngularの展望はAngularのValuesを軸にして予想できます。つまり、

Apps that users ❤ to use
Apps that developers ❤ to build
Community where everyone feels welcome

の3つです。なかでもひとつめの "Apps that users ❤ to use"が2020年の大きな目標になると考えています。

ng-conf 2019のkeynoteからスライドを引用すると、2018年から2019年にかけて、Angularの主なユースケースはエンタープライズアプリケーションでした。

エンタープライズアプリケーションは数は多いですが、ひとつひとつのアプリケーションのユーザーはそれほど多くありません。

エンタープライズアプリケーションの開発を支えるためにAngularが提供しているのは生産性とスケーラビリティです。Angular CLIによるコード生成や事前コンパイル、ビルドやテストの自動化はチーム開発の水準を高めてくれます。HTML/CSSによるUI開発は多くの開発者の慣れ親しんだ技術スタックです。

静的型チェックや型ベースのDependency Injectionシステムもスケーラビリティが重要な開発ユースケースを支えてきました。

2019年のAngularがIvyを通して取り組んだのは、まだ届いていないユースケースをカバーすることでした。まずはじめに取り組んだのはカジュアルなユースケースです。

デモやプロトタイプ、教材などユーザー数は少ないものの、何度も高速に、簡単に作る必要のあるアプリケーションです。

カジュアルなユースケースに求められるのは、開発スピードと軽量性です。

Ivyコンパイラで改善したTree-Shakingによるバンドルサイズの削減や、1コマンドでPWA化できる @angular/pwa ツール、さらには1コマンドでデプロイできる ng deploy コマンドなど、小さなアプリケーションを迅速に開発するためのツールを整えてきました。

StackblitzやUI Bakeryのようなビジュアルプロトタイピングツールもサードパーティから登場しており、Angularアプリケーションをカジュアルに作り始める道具は揃ってきています。

そして2020年、Angularが取り組むのは未踏の領域、大衆向けのアプリケーション開発のユースケースです。

eコマースやニュースサイトのような、コンシューマー向けの巨大な流入を持つユースケースでもAngularの3つのValuesを発揮できる仕組みを研究中です。

コンシューマー向けアプリケーションに求められるのはなんといってもWebパフォーマンスですが、それに加えて変化し続けるニーズに対応しつづけるための柔軟性です。

SEOやアクセシビリティ、国際化やモバイル対応、オフラインなど考慮すべきことが山のようにあります。このようなユースケースではベストプラクティスに固執するだけでなくプロダクトにとって最適な方法論を選べるように、フレームワーク側も柔軟である必要があります。

Ionic

コンシューマー向けのAngularアプリ開発としてはIonicが大きなシェアを持っています。ハイブリッドモバイルアプリを開発できるIonicはAngular CLIに対応し、 ng add コマンドで簡単にAngularプロジェクトに組み込めるようになりましたが、IonicはネイティブとのブリッジだけでなくUIコンポーネントライブラリの側面もあります。

プロダクトのUIをそのまま使い、ハイブリッドアプリに変換するインフラだけ欲しいというニーズのために、Ionicチームは Capacitorというインフラ部分だけのパッケージを提供し、これもまた ng add コマンドでAngularアプリケーションにインストールできるようにしました。

また、ビジュアルアプリ開発のためのIonic Studioを使えば、Angularコンポーネントのリアルタイムプレビューや、GUIでのプログラミングも可能です。モバイル向けAngularアプリケーションの開発プラットフォームとしてIonicが急速に成長しています。

Work in Progress

Angular公式にも取り組んでいるWork in Progressなプロジェクトがいくつかあります。

ひとつは新しいi18n APIです。これまでのAngularが提供するi18n機能はテンプレート内だけのものでしたが、現在実装中の機能はTypeScriptのコードのなかでも実行時にローカライズができるようになります。国際化が必要なアプリケーションの実装を大いに助けてくれるでしょう。

バンドルサイズのさらなる改善を目的に、コンポーネント単位での遅延読み込みも進行中です。これまではRoutingのページ単位でしたが、コンポーネントごとに遅延読み込みできるような仕組みを検討中です。

最後に、Project Photonを紹介します。ng-conf 2019で発表された研究段階のこのプロジェクトは、AngularアプリケーションにProgressive Hydrationを導入することが目的です。サーバーサイドレンダリングと遅延読み込みを組み合わせ、ユーザーが本当に必要とするまでJavaScriptを実行しないような仕組みを模索しています。詳しくはng-conf 2019のkeynoteを見てください。

Scully: Static Site Generator

新しい話題として、Angularのための静的サイトジェネレーター Scully が公開されました。Scullyは公式製ではなくコミュニティの有志で作られたサードパーティツールです。

これまでAngularにはGatsbyJSやGridsomeのような静的サイトジェネレーターは存在しなかったため、Scullyを起爆剤としてJAMstackもAngularのユースケースに加わっていくことでしょう。

2020年のAngular

2020年のAngularはパフォーマンス改善を続けながら、Ivy導入によって可能となったi18nを始めとするフレームワークAPIの開発・改善を重ねていくことで、これまで弱い部分だったコンシューマー向けのユースケースに手を伸ばしていくことでしょう。

Valuesの3本軸、ユーザーが愛せるアプリケーション（ユーザー体験）、開発者が愛せるアプリケーション（開発者体験）、そして世界中に広がるコミュニティの力で、これまで以上に魅力的なWeb開発プラットフォームに育っていくと期待しています。

それでは良いお年を。

なぜentryComponentsは非推奨になるのか

Suguru Inatomi — Mon, 04 Nov 2019 03:45:08 +0000

この記事では、Angular v9.0にて非推奨となる entryComponents 機能が、なぜ非推奨になるのかについてできるだけ簡単に解説します。

Angular - Deprecated APIs and Features

はじめに

解説を始める前に、重要な点をあらかじめ書き記しておきます。

もしIvyをオプトアウトする場合は、 entryComponents は引き続き必要です。決して削除しないでください。
いままで entryComponents 機能を使ったことがない方が新たになにか覚える必要はありません。興味がなければ過去のものとして無視してください。

`entryComponents` とは何なのか

v9.0 で非推奨となる entryComponents とは何だったのかということをまずは振り返りましょう。

entryComponents は多くの場合、 動的なコンポーネント を実現するために利用されます。動的なコンポーネントとは、AngularのテンプレートHTML内に登場せず、コードの実行によって生成されるコンポーネントです。テンプレートHTMLを静的に検査しても宣言が見つからないことから動的と呼ばれます。

Angular - 動的コンポーネントローダー

もっとも代表的なユースケースはダイアログやモーダルのようなケースです。コンポーネントクラスの処理が実行されることで動的にコンポーネントが表示されます。このようなコンポーネントはテンプレートHTML内に宣言されません。

たとえばAngular CDKのOverlay APIを使ってコンポーネントをオーバーレイ上に表示するには次のようなコードを書きます。

export class AppComponent {
    constructor(private overlay: Overlay) {}

    openModal() {
        const overlayRef = overlay.create();
        const modalPortal = new ComponentPortal(MyModalComponent);
        overlayRef.attach(modalPortal);
    }
}

このとき、動的に表示したい MyModalComponent は、それが宣言される NgModule の entryComponents 配列に追加される必要があります。

@NgModule({
    declarations: [AppComponent, MyModalComponent],
    entryComponents: [MyModalComponent],
})
export class AppModule {}

なぜ `entryComponents` が必要なのか

Angularに慣れている人にとっては、もはや当たり前のように「モーダルを実装するときは entryComponents 」というルーチンになってしまっているかもしれませんが、そもそもなぜこれが必要なのでしょうか。その理由は、Angular v8までのAoTテンプレートコンパイラと、そのテンプレートコンパイラが生成する実行コードに理由があります。

ここで以降の説明の簡単のため、v8以前のAoTコンパイラを ViewEngine (VE) コンパイラと呼びます。

コンポーネントの生成とComponentFactory

動的コンポーネントの生成には ComponentFactoryResolver というAPIを使います。このAPIはコンポーネントクラスから、そのコンポーネントに対してAoTコンパイラが生成した ComponentFactory オブジェクトを返すものです。

export class AppComponent {
  constructor(private cfr: ComponentFactoryResolver) {}

  ngOnInit() {
    const componentFactory = this.cfr.resolveComponentFactory(SomeComponent);
  }
}

先ほど紹介したCDKのOverlayやPortalの機能も、この ComponentFactoryResolver を利用しています。そして、 entryComponents に追加されたコンポーネントだけがこの resolveComponentFactory メソッドの引数に使えます。もし追加されていなければ次のようなエラーが表示されます。

つまり、 entryComponents とは、「あるコンポーネントのComponentFactoryを解決可能にする」ための機能であると言えます。ではなぜ entryComponents に追加されていないコンポーネントのComponentFactoryは解決できないのでしょうか。すべてのコンポーネントは等価ではないのでしょうか？

ViewEngineはTree-shakableなComponentFactoryを生成する

その答えは半分YESです。ViewEngineのAoTコンパイラは NgModule.declarations 配列に指定されたすべてのコンポーネントのComponentFactoryを生成しています。しかし、それが ComponentFactoryResolver から解決可能になっていないのです。

この様子は実際にAoTコンパイルの結果を見るとはっきりとわかります。Angular CLIのプロジェクトであれば、 ngc -p ./tsconfig.app.json とコマンドを実行すれば tsc-out ディレクトリにAoTコンパイル結果が出力されます。その中には、すべてのコンポーネントに対して ./some.component.ngfactory.js のような ComponentFactoryの生成コードを見ることができます。

これでViewEngineではどのコンポーネントにもComponentFactoryは存在していることがわかります。しかし、これらのComponentFactoryは どこからも参照されていません。つまりAngular CLI（の内部で使われているwebpack）のビルドでは、不要なコードとしてバンドルに含められないのです。これが、ComponentFactoryResolver によってComponentFactoryを解決できないコンポーネントがある理由です。バンドルサイズ削減のために、不要なコードを含めない仕組みになっているのです。

ComponentとComponentFactoryの分断

しかしこれはおかしい話です。ソースコード中で SomeComponent を参照しているのだからそのComponentFactoryは必要なコードとしてバンドルに含められるべきです。

ここがViewEngineの限界です。ViewEngineのAoTコンパイラはComponentFactoryの生成コードを元のコンポーネントクラスとは別のファイルに出力します。つまり、 some.component.ts に対して some.component.js と some.component.ngfactory.js を出力します。したがって、アプリケーションで SomeComponent への参照があったとしても、 SomeComponent のComponentFactoryには一切参照が届かないのです。

`entryComponents` は `ComponentFactoryResolver` をセットアップする

ここでようやく entryComponents の出番です。 NgModule の entryComponents に追加されたコンポーネントのComponentFactoryは、AoTコンパイラが特別に解釈して ComponentFactoryResolver で解決できるように参照を作ります。その様子は AoTコンパイル後の app.module.ngfactory.js で見ることができます。

AoTコンパイルの生成コードをはじめて見る方は驚くかもしれませんが、今回注目すべき点は2ヶ所。インポート文と ComponentFactoryResolver のプロバイダ宣言です。見ての通り、 AppModuleNgFactory から参照されているのは app.component.ngfactory だけです。そして、 ComponentFactoryResolver の近くにある配列には AppComponentNgFactory だけがセットされています。

それでは、 SomeComponent を entryComponents 配列に追加してもう一度AoTコンパイルしてみましょう。 app.module.ngfactory.js に変化があるはずです。

新たに some.component.ngfactory への参照が追加され、ComponentFactoryResolver の近くにある配列に SomeComponentNgFactory が追加されています。実はこの配列こそが ComponentFactoryResolverが解決できるコンポーネントのリストです。

つまり、entryComponents によって NgModule のコンパイル結果に影響を与えることで、動的に利用したいコンポーネントのComponentFactoryがTree-shakingされないように、ComponentFactoryResolver から解決可能な参照を保持することができるのです。

なぜ `entryComponents` が非推奨になるのか

ViewEngineにおいて entryComponents がなぜ必要だったかを簡単に説明しましたが、なぜv9からは非推奨となるのでしょうか。それはViewEngineに変わるAngularの新しい IvyコンパイラがViewEngineの抱える問題を根本から解決したからです。

Ivyは同一ファイルにコード生成する

IvyのAoTコンパイラは元のコンポーネントファイルと同じファイル、しかも同じクラスの静的フィールドとしてコード生成します。実際にAoTコンパイル結果を見てみましょう。v9では次のような生成コードになります。IvyではAoTコンパイルによって追加される独自のファイルは一切ありません。

some.component.js は次のようになっています。3行目にあるのは元の SomeComponent から @Component デコレーターが除去されたクラスです。そしてデコレーターの中に定義されていたセレクターやテンプレートなどのメタデータが、 9行目以降のAoTコンパイラによる生成コードに変換されています。

ここで重要なことは、 SomeComponent のAoTコンパイル後コードが、 SomeComponent クラスと密に結合していることです。これにより、 SomeComponent を参照すれば自動的に SomeComponent のコンポーネント生成に必要なすべての情報を解決できます。

つまり、 app.module.js で some.component.js をインポートしているだけで、 SomeComponent のComponentFactoryは解決可能になるのです。

これが、 Angular v9でIvyによって entryComponents が非推奨になる理由です。 entryComponents の代替となる新たな方法に変わるのではなく、そもそも根本的に動的コンポーネントと静的コンポーネントを区別する必要がなくなるのです。

Tree-shakingの問題は？

ここまで読んだ方はもしかすると entryComponents がなくなることで、ViewEngineと比べてバンドルサイズが増えるのではないかと疑っているかもしれません。確かに、コンポーネントの生成コードだけを考えると、ViewEngineと比べてTree-shaking可能な領域は減っています。しかしIvyではその他のいくつもの改善によってトータルではほとんどのユースケースでバンドルサイズが削減されます。

もっとも大きな改善は、Angularのテンプレート機能がTree-shakableになることです。詳細は割愛しますが、 [prop]="someValue" や (eventName)="onEvent($event)" など、すべてのテンプレートの機能が個別にTree-shakingされます。アプリケーションで一度も使わなかったテンプレート機能はバンドルに含まれません。

また、コンポーネントと生成コードが同一ファイルになることでクラス定義やimport/exportのオーバーヘッドもなくなり、より少ないコードだけを生成すればよくなりました。また、ViewEngineではコンポーネントが子コンポーネントになる場合とホストコンポーネントになる場合で別の生成関数を定義していましたが、Ivyではひとつの生成関数に統合されるので、これによっても生成コードのサイズは減っています。

トレードオフはありつつも、Ivyでは差分コンパイルのスピード、バンドルサイズの削減、内部アーキテクチャの単純化などの複合的な視点で、Ivyのアーキテクチャを選択しています。

動的コンポーネントを超えた遅延コンポーネントへ

IvyのAoTコンパイラは同一クラスの静的フィールドにComponentFactoryを生成すると説明しました。この変更による恩恵は entryComponents が不要になるだけではありません。ひとつのコンポーネントに関するコードが1ファイルに含まれることで、Dynamic Importによるコンポーネントの遅延読み込みも将来的には可能になります。

つまり、次のように動的な import() 文で取得した SomeComponent クラスでも ComponentFactoryResolver で解決できるということです。

export class AppComponent {
  constructor(private cfr: ComponentFactoryResolver) {}

  ngOnInit() {
    import('./some/some.component')
      .then(m => this.cfr.resolveComponentFactory(m.SomeComponent))
      .then(someCompFactory => {
        console.log(someCompFactory);
      });
  }
}

IvyではすべてのコンポーネントのComponentFactoryがバンドルに含められると説明しましたが、それはテンプレートHTMLやTypeScriptコードの中で 静的に 参照されている場合だけです。もし SomeComponent がこの Dynamic Import以外でまったく参照されていなければ、 Angular CLIは SomeComponent そのものを別バンドルに分離し、遅延読み込み可能にします。モーダル用のコンポーネントであれば、初期読込されるJavaScriptにはコンポーネントを含めず、モーダルを表示するイベントが発生したときに初めて遅延読み込みすればいいわけです。

このようにViewEngineからIvyにアーキテクチャ変更したことによって、いままでは覚えるしかなかった「Angularではできない」や「Angularではこのようにする」といった慣例的な制約がいくつも取り払われていきます。そして不要になった（陳腐化した）APIは非推奨となっていきます。

非推奨化は必ずしも代替APIへの置き換えを意味するわけではないということを覚えておきましょう。

まとめ

v8までのViewEngineでは entryComponents が無ければComponentFactoryの解決ができなかった
Ivyではすべてのコンポーネントが常にComponentFactoryを保持しているため、いつでもどのコンポーネントも動的に利用できるようになる
entryComponents の非推奨化は代替APIへの置き換えではなく、そもそも動的コンポーネントと静的コンポーネントの区別が不要になったということである

Ivyについての詳しい話は、 AngularConnect 2019での次のセッションをおすすめします。

Managing Key-Value Constants in TypeScript

Suguru Inatomi — Tue, 20 Aug 2019 15:24:08 +0000

A lot of applications have a dropdown select menu in a form. Let's imagine a form control like below;

Typically, each select menu's item has ID and label. The ID is responsible to communicate with other components, services, or server-side. The label is responsible to display text for users.

This post explains how to manage constants for the menu items which has ID and mapping for its label. It uses TypeScript's as const feature which is introduced since v3.4.

Define colorIDs Tuple

In TypeScript, a tuple is an array, but its length and items are fixed. You can define a tuple with as const directive on the array literal. (as const directive needs TypeScript 3.4+)

Create colors.ts and define colorIDs tuple as following;

export const colorIDs = ['green', 'red', 'blue'] as const;

The type of colorIDs is not string[] but ['green', 'red', 'blue'] . Its length is absolutely 3 and colorIDs[0] is always 'green'. This is a tuple!

Extract ColorID Type

A Tuple type can be converted to its item's union type. In this case, you can get 'green' | 'red' | 'blue' type from the tuple.

Add a line to colors.ts like below;

export const colorIDs = ['green', 'red', 'blue'] as const;

type ColorID = typeof colorIDs[number]; // === 'green' | 'red' | 'blue'

Got confusing? Don't worry. It's not magic.

colorIDs[number] means "fields which can be access by number", which are 'green' , 'red', or 'blue' .

So typeof colorIDs[number] becomes the union type 'green' | 'red' | 'blue'.

Define colorLabels map

colorLabels map is an object like the below;

const colorLabels = {
  blue: 'Blue',
  green: 'Green',
  red: 'Red',
};

Because colorLabels has no explicit type, you cannot notice even if you missed to define red 's label.

Let's make sure that colorLabels has a complete label set of all colors! ColorID can help it.

TypeScript gives us Record type to define Key-Value map object. The key is ColorID and the value is string. So colorLabels 's type should be Record<ColorID, string> .

export const colorIDs = ['green', 'red', 'blue'] as const;

type ColorID = typeof colorIDs[number];

export const colorLabels: Record<ColorID, string> = {
  green: 'Green',
  red: 'Red',
  blue: 'Blue',
} as const;

When you missed to define red field, TypeScript compiler throw the error on the object.

By the way, Angular v8.0+ is compatible with TypeScript v3.4. The demo app in the above is the following;

import { Component } from '@angular/core';
import { FormControl } from '@angular/forms';

import { colorIDs, colorLabels } from './colors';

@Component({
  selector: 'app-root',
  template: `
    <label for="favoriteColor">Select Favorite Color:&nbsp;</label>
    <select id="favoriteColor" [formControl]="favoriteColorControl">
      <option *ngFor="let id of colorIDs" [ngValue]="id">
        {{ colorLabels[id] }}
      </option>
    </select>
    <div>Selected color ID: {{ favoriteColorControl.value }}</div>
  `,
})
export class AppComponent {
  readonly colorIDs = colorIDs;
  readonly colorLabels = colorLabels;

  readonly favoriteColorControl = new FormControl(this.colorIDs[0]);
}

Conclusion

as const turns an array into a tuple
typeof colorIDs[number] returns an union type of its item
Define an object with Record<ColorID, string> for keeping a complete field set.

DEV Community: Suguru Inatomi

Building Browser Extensions with WXT + Angular

lacolaco / wxt-angular-starter

Browser extension starter template using WXT and Angular

WXT + Angular Starter

Features

Quick Start

Available Scripts

Project Structure

What is WXT

Building Browser Extensions with Angular

Project Structure

Setup Steps

1. Initialize WXT Project

2. Install Dependencies

3. Pin Vite Version

4. Configure WXT

5. Configure TypeScript

6. Create Angular Popup

Development and Build

Summary

Understanding Angular Ivy Library Compilation

How to compile libraries with Ivy

Terminology

Ivy compilation for applications

Analysis step

Code generation step

Locality

Runtime compatibility

Library compilation

ngcc

Ivy library compilation

LTO compilation (Pre-Publish compilation)

Linking libraries

Wrap-up

Angular: Using NgRx Store with Redux Toolkit 🚀

What is the Redux Toolkit (RTK)?

The concept of Slice

NgRx Store with RTK

StoreModule.forFeature() and Slice

0. Setup NgRx Store

1. Create a counter slice

2. Make a “ducks” module

3.Setup StoreModule.forFeature()

4. Creating a Feature selector

5. Access to Feature State

Advantages and disadvantages

Advantage: minimized boilerplate

Advantage: Redux Ecosystem

Disadvantage: Increased bundle size

Conclusion

Angular: Eliminate Render Blocking Requests の概要

概要

背景

解決案

CSS の非同期読み込み

CSS Files Budget

Google Fonts と Icons のインライン化

クリティカル CSS の抽出

Angular Universal (SSR)

App-Shell / Pre-rendering

Client Side Rendering （CSR）

代替案

明示的なクリティカル CSS 定義

ヘッドレスブラウザによるクリティカル CSS 抽出

ルートコンポーネントでのグローバル CSS 読み込み

DNS-Prefetch と Preconnect Hints

RFC のフィードバック

まとめ

Angular: Lightweight Injection Tokenという新しいテクニック

Lightweight Injection Tokenの概要

なぜ今なのか、これまでの経緯

コンポーネント以外のLightweight Injection Token

参考リンク

Angular Elements: Composable Definition Pattern

Creating Lib1ElementsModule

Creating Lib2ElementsModule

Initial Null Problem of AsyncPipe and async data-binding

How AsyncPipe works

Initial Null Problem

`StoreModule.forFeature()` and Slice

3.Setup `StoreModule.forFeature()`

Creating `Lib1ElementsModule`

Creating `Lib2ElementsModule`

`gen-bundle`時の動き

`entryComponents` とは何なのか

なぜ `entryComponents` が必要なのか

`entryComponents` は `ComponentFactoryResolver` をセットアップする

なぜ `entryComponents` が非推奨になるのか