DEV Community: Michael Muscat

Playing with Providers

Michael Muscat — Sun, 17 May 2020 07:20:12 +0000

Dependency injection is one of Angular's most powerful features. Angular Ivy supercharged this with bloom filters and monomorphism while adding more options for providedIn to configure the scope of tree-shakable providers.

After digging into Angular, here's 3 things you may not know about providers:

1. `inject()`

Under the hood Angular uses code reflection to work out what the dependencies of your classes are. Let's look at an example:

@Injectable()
export class ApiService {
    constructor(private http: HttpClient) {}
}

All well and good. We know that when Angular compiles this code it will detect the HttpClient type annotation and wire up ApiService so that it is provided with an instance of Httpclient when it is constructed by Angular.

We can write this another way.

export class ApiService {
    private http = inject(HttpClient)
}

This code doesn't use Reflection, so we can omit @Injectable(). We are now imperatively fetching the dependency using the service locator pattern. This means class dependencies are hidden within the closure of the class constructor unless we expose it. We can't replace them through the constructor arguments during testing either, but we can still use TestBed to configure the injector.

2. Injection Context

But why does this work? The documentation says:

Must be used in the context of a factory function such as one defined for an InjectionToken. Throws an error if not called from such a context.

This is interesting, just what exactly qualifies as a factory function? It says we can use it inside InjectionToken.

const IS_BROWSER = new InjectionToken<boolean>("IS_BROWSER", {
    factory() {
        const platformId = inject(PLATFORM_ID)
        return isPlatformBrowser(platformId)
    }
})

Well that's convenient. It turns out we can call inject inside any injectable function, class, or factory. Thats means everything that goes in the providers arrays.

const GLOBAL = new InjectionToken<any>("GLOBAL")

const FACTORY_PROVIDER = {
    provide: GLOBAL,
    useFactory: () => {
        return inject(IS_BROWSER) ? window : global
    }
}

Whenever Angular injects a value, it uses a context aware injector that knows where it is in the injector hierarchy. We can create this context ourselves.

const spy = fn()

class Context {
    constructor() {
        spy(inject(INJECTOR))
    }
}

const parent = Injector.create({
    providers: [Context]
})

const child = Injector.create({
    parent,
    providers: [Context]
})

child.get(Context)

expect(spy).toHaveBeenCalledWith(child)

child.get(Context, null, InjectFlags.SkipSelf)

expect(spy).toHaveBeenCalledWith(parent)

3. Type Safety

Let's return to the documentation to see what else it says about inject().

Within such a factory function, using this function to request injection of a dependency is faster and more type-safe than providing an additional array of dependencies (as has been common with useFactory providers).

Faster and more type safe. That's great! It's also much more ergonomic when dealing with factory providers, value providers, or generics.

const API_KEY = new InjectionToken<string>("API_KEY")

@Injectable()
class ApiService {
    constructor(@Inject(API_KEY) private apiKey: string) {}
}

This code is not type safe! The constructor is not checked to ensure that string matches the signature of @Inject(API_KEY). It's also verbose.

class ApiService {
    private apiKey = inject(API_KEY) // inferred as string
}

For generics we can write a wrapper function.

function injectStore<T>(store = Store): Store<T> {
    return inject(store)
}

class NgService {
    private store = injectStore<AppState>() // inferred as Store<AppState>
}

Caveats

Only call inject() synchronously inside the factory/constructor!

You might be thinking, what about components? Sadly, components, directives and pipes (ie. declarations) are not created inside an injection context.

@Component()
export class NgComponent {
    // Error: inject() must be called from an injection context
    private http = inject(HttpClient) 
}

There are also issues when trying to inject abstract types, such as ChangeDetectorRef.

export class NgService {
    // Type error, no matching overload
    private cdr = inject(ChangeDetectorRef) 
}

This actually works at runtime but the type signature only allows concrete classes.

If you're feeling adventurous there is a workaround to both of these issues with the help of private APIs.

import { ɵɵdirectiveInject, Type, AbstractType, InjectionToken, ChangeDetectorRef } 
    from "@angular/core"

export function inject<T>(
    token: Type<T> | AbstractType<T> | InjectionToken<T>,
    flags?: InjectFlags,
): T {
    return ɵɵdirectiveInject(token as any, flags)
}

@Component()
export class NgComponent {
    // it works!
    private cdr = inject(ChangeDetectorRef) 
}

ɵɵdirectiveInject is the injector used internally by Angular when compiling your components and directives into defineXXX factories.

class SomeDirective {
    constructor(directive: DirectiveA) {}

    static ɵdir = ɵɵdefineDirective({
        type: SomeDirective,
        factory: () => new SomeDirective(ɵɵdirectiveInject(DirectiveA))
    });
 }

Does this sort of thing interest you? I'm looking for contributors to help build a Composition API for Angular.

Thanks for reading!

Exploring the Angular Effects API

Michael Muscat — Sun, 08 Mar 2020 17:42:45 +0000

This article covers some of the finer points to help you get more out of Angular Effects. You can also jump forward to see a worked example that puts many of these concepts into practice.

This is part V in a series on Reactive State in Angular. Read Part IV: Extending Angular Effects with effect adapters

Multiple bindings

When writing effects, we can bind their emissions to properties on the connected component. We can also choose to bind multiple effects to a single property. Use this technique when properties receive values from several mutually exclusive observable sources.

@Component()
export class AppComponent {
    count = 0

    @Effect("count")
    incrementCount(state: State<AppComponent>) {
        return state.count.pipe(
            take(1),
            increment(1),
            repeatInterval(1000)
        )
    }

    @Effect("count")
    multiplyCount(state: State<AppComponent>) {
        return state.count.pipe(
            take(1),
            multiply(2),
            repeatInterval(5000)
        )
    }
}

In this example count will be incremented once every second, with its value being multiplied by two every five seconds. Each effect runs independently of one another.

Assignment bindings

Property bindings bind a value stream to a single property. Assignment bindings are like property bindings, except we can update multiple properties on the connected component at the same time. Effects with assignment bindings must emit objects that match the partial signature of the component it is bound to.

@Component()
export class AppComponent {
    name = ""
    version = undefined

    @Effect({ assign: true })
    incrementCount(state: State<AppComponent>) {
        return of({
            name: "Angular",
            version: {
                major: 9,
                minor: 0,
                patch: 0
            }
        })
    }
}

Under the hood assignment bindings use Object.assign() to assign values emitted from each effect.

Module effects

Angular Effects can be used inside modules to create global effects. This is useful for mapping websocket channels to global state, global event handling or other side effects that do not depend on local component state.

@Injectable({ providedIn: "root" })
export class GlobalEffects {
    websocket = new WebSocketSubject()

    @Dispatch(Authorized)
    authorized() {
        return this.websocket.pipe(
            filter(event => event.type === "AUTHORIZED")
        )
    }
}

@NgModule({
    providers: [Effects]
})
export class AppModule {
    constructor(connect: Connect) {
        connect(this)
    }
}

NOTE: See Effect adapters: Integrating Angular Effects with @ngrx/store for more information about @Dispatch().

This example shows how we can dispatch an action when the websocket connection receives messages matching a given pattern. Keep in mind that when using effects with modules, some options such as markDirty and detectChanges will have no effect.

Special injection tokens

Locally provided effect services have access to the component's Injector. This means we can inject special tokens that are only available to the component, such as ElementRef, TemplateRef, Renderer and ViewContainerRef. When working with components we can extract these dependencies into our effect services.

interface ButtonLike {
    disabled: boolean
    press: HostEmitter<MouseEvent>
}

@Injectable()
export class ButtonEffect {
    constructor(private elementRef: ElementRef, private renderer: Renderer2) {}

    @Effect("press")
    allowClick(state: State<ButtonLike>) {
        const eventPattern = handler => this.renderer.listen(this.elementRef.nativeElement, "click", handler)

        return fromEventPattern(eventPattern).pipe(
            withLatestFrom(state.disabled, (event, disabled) => disabled ? false : event),
            filter(Boolean)
        )
    }
}

@Component({
    providers: [Effects, ButtonEffect]
})
export class ButtonComponent implements ButtonLike {
    @Input()
    disabled = false

    @Output()
    press = new HostEmitter<MouseEvent>()

    constructor(connect: Connect) {
        connect(this)
    }
}

NOTE: Remember that you must provide your effects in the local component providers array to gain access to that component's injector.

This example demonstrates how we can use special injection tokens to extract the behaviour of a button component into a reusable trait. We are able to cleanly decouple the button's state from its behavior.

HostRef

HostRef is a special injection token that gives components the ability to observe its own state. Every effect we write is provided three arguments that are populated from this token: state, context and observer. See Getting Started: Arguments for more information.

We can inject this token in our connected components and effect services.

@Injectable()
export class AppEffects {
    context: AppComponent
    state: State<AppComponent>
    observer: Observable<AppComponent>

    constructor(hostRef: HostRef<AppComponent>) {
        this.context = hostRef.context
        this.state = hostRef.state
        this.observer = hostRef.observer
    }
}

We can also inject the parent HostRef to observe the state of a connected parent.

@Injectable()
export class ChildEffects {
    constructor(@SkipSelf() parent: HostRef<ParentComponent>) {}
}

Lastly, we can query and observe the state of connected child components.

interface ChildComponent {
    count: number
}

@Component()
export class ParentComponent {
    @ViewChild(ChildComponent, { read: HostRef })
    childRef: HostRef

    @Effect({ whenRendered: true })
    logChildCount(state) {
        return state.childRef.pipe(
            switchMap(childRef => childRef.state.count)
        ).subscribe(count => console.log(count))
    }
}

As these examples demonstrate, direct use of HostRef is useful when building tightly coupled reactive components.

Two-way observable state: Renderless select

Putting these concepts into practice, here is a working demo of a select component powered by Angular Effects. It demonstrates how we can use HostRef to create two-way observable state, putting components together with renderless traits, and more.

Experimental features

These features rely on unstable APIs that could break at any time.

Zoneless change detection

Zoneless change detection depends on experimental Ivy renderer features. To enable this feature, add the USE_EXPERIMENTAL_RENDER_API provider to your root module.

Zones can be disabled by commenting out or removing the following line in your app's polyfills.ts:

import "zone.js/dist/zone" // Remove this to disable zones

In your main.ts file, set ngZone to "noop".

platformBrowserDynamic()
    .bootstrapModule(AppModule, { ngZone: "noop" }) // set this option
    .catch(err => console.error(err))

Global connect hook

Global hooks are a new feature in Angular. By using some private APIs we don't have to explicitly inject the Connect service to connect our components.

@Component({
    providers: [Effects]
})
export class AppComponent {
    count = 0
    // global connect hook
    constructor() {
        connect(this)
    }

    @Effect("count")
    incrementCount() {
        // etc
    }
}

Connect API

NOTE: Under the hood, this the mechanism that makes effects run. This is not a stable API so use it at your own risk.

If you are familiar with APP_INITIALIZER, it's like that except for components and directives. To create a service that is automatically instantiated when the component or directive is "connected" (ie. by calling connect()), add a multi provider to your providers array similar to this one.

@Injectable()
export class MyConnectedService {
    constructor(hostRef: HostRef) {}
}

export const INITIALIZERS = [{
    provide: HOST_INITIALIZER,
    useValue: MyConnectedService,
    multi: true
}]

export const CONNECTED = [
    MyConnectedService,
    CONNECT,
    INITIALIZERS
]

@Component({
    providers: [CONNECTED]
})
export class MyComponent {
    constructor(connect: Connect) {
        connect(this)
    }
}

When the component is created in this example, MyConnectedService will be instantiated and have access to the HostRef.

Diving deep into Angular

Thank you for reading this series on Angular Effects. In the final article of this series, I will take you on a deep dive into the inner workings of Angular Effects and how it's made possible through some rarely used APIs, some experimentation and the hard work of the Angular team to bring us stable Ivy.

Next in this series

Part I: Introducing Angular Effects
Part II: Getting started with Angular Effects
Part III: Thinking reactive with Angular Effects
Part IV: Extending Angular Effects with effect adapters
Part V: Exploring the Angular Effects API (You are here)
Part VI: Deep dive into Angular Effects

Extending Angular Effects with effect adapters

Michael Muscat — Thu, 05 Mar 2020 11:20:05 +0000

So far we have seen how Angular Effects empowers developers to write more reactive applications by removing a lot of the friction involved in wiring components. Effect adapters takes this concept a step further by extracting behavior to write more concise and descriptive effects. At a glance we should be able to infer the behavior of an effect without reading its implementation. This article walks you through several examples to help you understand and write your own effect adapters.

This is part IV in a series on Reactive State in Angular. Read Part III: Thinking reactive with Angular Effects

We extend effects by writing an effect adapter. Effect adapters are injectable services that implement the EffectAdapter interface. Let's start with a basic logger.

@Component()
export class CountComponent {
    count = 0

    @Effect()
    logCount(state: State<CountComponent>) {
        return state.count.subscribe(count => console.log(count))
    }
}

Here's an effect that logs the count without using adapters. Let's write an effect adapter that does this for us.

@Injectable({ providedIn: "root" })
export class Log implements EffectAdapter<any> {
    next(value: any) {
        console.log(value)
    }
}

TIP: For better readability, effect adapters should be named with a verb.

Here we have a very simple effect adapter. If you're familiar with observers, you'll see how this works in a moment. Before using an effect adapter, we have to provide it in our app. In this case we have added it to the "root" provider.

TIP: Where we provide the adapter matters, as this will affect the context of any injected dependencies.

Now the adapter can be used in any of our effects.

@Component()
export class CountComponent {
    count = 0

    @Effect(Log)
    logCount(state: State<CountComponent>): Observable<number> {
        return state.count
    }
}

Output:
> 0

Notice that the effect now returns an observable. The Log adapter subscribes to it, logging its emitted values.

Effect adapters can also specify options to be passed through the @Effect() decorator, as well as the effect return type. Adding to the previous example:

export interface LogOptions {
    prefix: string
}

@Injectable({ providedIn: "root" })
export class Log implements EffectAdapter<string, LogOptions> {
    next(value: string, metadata: EffectMetadata<string>) {
        console.log(`${metadata.options.prefix} ${value}`)
    }
}

@Component()
export class CountComponent {
    count = 0

    @Effect(Log, { prefix: "count:" })
    logCount(state: State<CountComponent>) {
        return state.count.pipe(
            map(String)
        )
    }
}

Output:
> "count: 0"

One last thing effect adapters can do is transform effects, modifying the return value before it is processed. Effects can then return arbitrary values.

@Injectable({ providedIn: "root" })
export class LogState implements EffectAdapter<State<any>> {
    create(state: State<any>) {
        return latest(state)
    }

    next(values: {[key: string]: any}) {
        console.log(values)
    }
}

@Component()
export class CountComponent {
    count = 0

    @Effect(LogState)
    logState(state: State<CountComponent>) {
        return state
    }
}

Output:
> { count: 0 }

That's everything you need to know to get started writing your own adapters. Let's look at a more practical example.

Integrating Angular Effects with `@ngrx/store`

With Angular Effects, mapping global state to our components has never been easier. Consider the following example:

interface AppState {
    count: number
}

export const selectCount = (state: AppState) => state.count

@Component({
    template: `
        <p *ngIf="count$ | async as count">
            {{ count }}
        </p>
        <button (click)="incrementCount()"></button>
    `
})
export class AppComponent {
    count$ = this.store.select(selectCount).pipe(
        startWith(0)
    )

    incrementCount() {
        this.store.dispatch({
            type: "INCREMENT_COUNT"
        })
    }

    constructor(private store: Store<AppState>) {}
}

Here we have a component that maps global count state to a local count variable inside the template of a component. We're already familiar with the problems that come with this approach, and now there's two new problems.

First, the store is now strongly coupled to the component. This is more difficult to test since we have to set up additional mocks that set up global state. The ceremony of connecting and dispatching state quickly adds up to create cluttered components that are difficult to read. The current best practice with NgRx recommends using facade classes, but this introduces another layer of indirection when the redux pattern is already complicated enough as it is.

The second problem is that there's no obvious way to read the current state of the component in the dispatch method. What if we wanted to pass the current count value as a payload argument? There are ways, but it's not easy.

Let's see how Angular Effects elegantly solves both of these problems:

@Component({
    template: `
        <p>{{ count }}</p>
        <button (click)="incrementCount(count)"></button>
    `
})
export class AppComponent {
    count = 0

    @Effect("count")
    selectCount() {
        return this.store.select(selectCount)
    }

    incrementCount(count) {
        this.store.dispatch({
            type: "INCREMENT_COUNT",
            payload: count
        })
    }

    constructor(private store: Store<AppState>) {}
}

By moving async out of the template, we can now read the current state at any time and pass this to our dispatched action. However we still haven't decoupled the store dependency. This is where we can leverage Effect adapters.

@Component({
    template: `
        <p>{{ count }}</p>
        <button (click)="increment(count)"></button>
    `
})
export class AppComponent {
    count = 0
    increment = new HostEmitter<number>()

    @Effect(Select)
    mapStateToProps(): MapStateToProps<AppState, AppComponent> {
        return {
            count: selectCount
        }
    }

    @Effect(Dispatch, "INCREMENT_COUNT")
    incrementCount(state: State<AppComponent>) {
        return state.increment
    }
}

Note the semantics of the effect adapters utilized here. The Select effect selects state. The Dispatch effect dispatches actions. By naming effect adapters correctly we can improve the readability of code on top of the added functionality.

Angular Effects doesn't provide any adapters out of the box, so here are sample implementations to help you write your own. These demonstrate the use case for both types of effect adapters:

@Injectable({ providedIn: "root" })
export class Dispatch implements EffectAdapter<any, string> {
    constructor(private store: Store) {}

    public next(payload: any, metadata: EffectMetadata<string>): void {
        this.store.dispatch({
            type: metadata.options,
            payload
        })
    }
}

export type MapStateToProps<T, U> = {
    [key in keyof U]?: (state: T) => U[key]
}

@Injectable({ providedIn: "root" })
export class Select implements EffectAdapter<MapStateToProps<any, any>> {
    constructor(private store: Store<any>) {}

    public create(mapState: MapStateToProps<any, any>, metadata: EffectMetadata) {
        metadata.options.assign = true

        const sources = Object.entries(mapState).map(([prop, selector]) =>
            this.store.pipe(
                select(selector!),
                map(value => ({ [prop]: value })),
            ),
        )

        return merge(...sources)
    }
}

Since these will probably get used a lot, with a little more work we can turn these into custom decorators. I'll leave that as an exercise to the reader. The final code in our app then looks like this.

export class AppComponent {
    count = 0
    increment = new HostEmitter<number>

    @Select()
    public mapStateToProps(): MapStateToProps<AppState, AppComponent> {
        return {
            count: selectCount,
        }
    }

    @Dispatch(IncrementCount)
    public incrementCount(state: State<AppComponent>) {
        return state.increment
    }
}

We have managed to decouple the store and make the component completely reactive. The result is a component that is easier to test, easier to to read and easier to write. If we wanted we could even go one step further and extract the effects into a separate effects service. Components are then reduced to simple state containers and event emitters with a template attached to them.

Implementing a `shouldComponentUpdate` lifecycle hook

For this example, we'll implement an effect adapter that stops the component from being rendered until it meets a certain condition.

@Component({
    template: `{{ count }}`,
    providers: [Effects, ShouldComponentUpdate]
})
export class CountComponent {
    @Input()
    count = 0

    @Effect(ShouldComponentUpdate)
    shouldComponentUpdate(state: State<CountComponent>): Observable<boolean> {
        return state.count.pipe(
            map(count => count > 10)
        )
    }

    constructor(connect: Connect) {
        connect(this)
    }
}

Here we have written an effect, shouldComponentUpdate that returns a boolean observable. We'll use this boolean value to attach or detach the view from change detection.

NOTE: Notice how we provide the effect adapter ShouldComponentUpdate in the local component providers instead of the root. We do this so the adapter has access to the component's ChangeDetectorRef, as shown below.

@Injectable()
export class ShouldComponentUpdate implements EffectAdapter<boolean> {
    constructor(private cdr: ChangeDetectorRef) {
        this.cdr.detach()
    }

    next(shouldUpdate: boolean) {
        if (shouldUpdate) {
            this.cdr.reattach()
        } else {
            this.cdr.detach()
        }
    }
}

Now when we use this component, it will only render itself when the value of count is greater than 10. Effect adapters lets you extract behavior from your components so they can be expressed purely in terms of reactive state.

More effective components

In this article we covered the basics of writing effect adapters and demonstrated through example how they can be used to write more effective components. At this point, we have covered almost everything there is to know about Angular Effects. The next article will explain some of the finer points of the Angular Effects API.

Next in this series

Part I: Introducing Angular Effects
Part II: Getting started with Angular Effects
Part III: Thinking reactive with Angular Effects
Part IV: Extending Angular Effects with effect adapters (You are here)
Part V: Exploring the Angular Effects API
Part VI: Deep dive into Angular Effects

Thinking reactive with Angular Effects

Michael Muscat — Tue, 03 Mar 2020 19:24:52 +0000

One of the characteristics of reactive systems is that the timing of certain things becomes irrelevant. Angular Effects changes the way you think about components.

This is part III in a series on Reactive State in Angular. Read Part II: Getting started with Angular Effects

Up until now we've been trained to use imperative lifecycle hooks to make components work. This is fine if you stick with imperative code. The ceremony required to make these hooks reactive however, has lead to verbose and brittle code that is hard to read, test or maintain.

Angular Effects takes a different approach. Instead of subscribing to lifecycle hooks, we subscribe to the component state itself. We are then able to observe when certain properties have changed and create effects that respond to those changes through the composition of observable streams. Whether we subscribe early, or subscribe late, the timing of state changes does not really matter. As a result, we might not need lifecycle hooks at all!

How to use Angular Effects

To realign yourself into thinking about components reactively, this article will walk you through some common Angular concepts and their usage with Angular Effects.

Input bindings

Perhaps the most important part of components is receiving and responding to inputs. Here's how you can observe inputs without ngOnChanges or setters.

@Component({
    template: `{{ count }}`
})
export class CountComponent {
    @Input()
    count = 0

    @Effect()
    logCountChanges(state: State<AppComponent>) {
        return changes(state.count).subscribe(count => console.log(count))
    }
}

TIP: The changes() operator is the same as skip(1), and is used to indicate that we are only interested in observing changes to the state, not the initial value.

This component is set up to log count whenever it changes. If we set the input value to 10:

<app-count [count]="10"></app-count>

Output:
> 10

As expected, we observe that the input value has changed. This works for non-input values as well.

@Component({
    template: `{{ count }}`
})
export class CountComponent {
    count = 0

    @Effect()
    logCountChanges(state: State<AppComponent>) {
        return changes(state.count).subscribe(count => console.log(count))
    }

    @Effect("count")
    setCount() {
        return scheduled(from([10, 20, 30]), asyncScheduler)
    }
}

Here we create a binding effect to update count when it emits. This time however we have removed the @Input() decorator.

<app-count></app-count>

Output:
> 10
> 20
> 30

We still observe the changes, even though it's not an input. When used with bindings, effects also trigger change detection to update the view. Kind of like an async pipe 🤔

Want to observe the entire state?

@Component()
export class AngularComponent {
    @Input()
    name = "angular"

    @Input()
    version = {
        major: 9,
        minor: 0,
        patch: 0
    }

    @Effect()
    logState(state: State<AppComponent>) {
        return latest(state).subscribe(({ name, version }) => console.log(name, version))
    }
}

TIP: latest() is a small wrapper around combineLatest that lets you pass in a sources object, similar to forkJoin.

TIP: You can replicate the behaviour of ngOnChanges by using the pairwise operator to get the previous and current values of the state you are observing.

Output bindings

We can connect effects to outputs in a couple of ways. We can connect it imperatively by subscribing to it:

@Component()
export class CountComponent {
    @Input()
    count = 0

    @Output()
    countChange = new EventEmitter(true)

    @Effect()
    emitCount(state: State<AppComponent>, context: Context<CountComponent>) {
        return state.count.subscribe(context.countChange)
    }
}

Or we can connect it with an observer binding by using HostEmitter. HostEmitter is a drop-in replacement for EventEmitter that makes it easier to work with Angular Effects.

@Component()
export class CountComponent {
    @Input()
    count = 0

    @Output()
    countChange = new HostEmitter(true)

    @Effect("countChange")
    emitCount(state: State<AppComponent>) {
        return state.count
    }
}

The effect is the same as the first example, just more concise.

NOTE: Angular Effects only supports observer bindings when using HostEmitter. See the first example for imperative usage with EventEmitter or other RxJS subjects.

A note on `ExpressionChangedAfterItHasBeenCheckedError`

You might see this error at some point when using Angular Effects. It tends to happen when effects emit values that update a parent component (via outputs) after the view has been checked. You can avoid this error by passing true to the constructor of EventEmitter or HostEmitter as seen in the examples above. This causes outputs to be emitted asynchronously, thus avoiding the error.

Host bindings

Host bindings need no extra treatment when using Angular Effects. It's just easier to use them when they are derived from observable data.

@Component()
export class BoxComponent {
    @HostBinding("style.width.px")
    width = 0

    @HostBinding("style.height.px")
    height = 0

    @Effect("width")
    setWidth(state: State<AppComponent>) {
        return of(1024)
    }

    @Effect("height")
    setHeight(state: State<AppComponent>) {
        return of(768)
    }
}

Bound effects trigger change detection when values are emitted, which in turn updates host bindings.

Host listeners

The @HostListener decorator doesn't work with event emitters, requiring additional boilerplate to connect it with an observable. Angular Effects solves this with HostEmitter, which talks like an event emitter but walks like a function.

@Component()
export class ClickComponent {
    constructor(private elementRef: ElementRef<HTMLElement>) {}

    @HostListener("click", ["$event"])
    clicked = new HostEmitter<MouseEvent>()

    @Effect()
    handleClick(state: State<AppComponent>) {
        return state.clicked.subscribe(event => console.log(event))
    }
}

Normally we might access an event emitter from the Context argument to use it inside our effects. We keep HostEmitter unwrapped inside State for extra convenience.

Template listeners

If we bind template events to a HostEmitter instead of a function or event emitter, using them inside effects is trivial.

@Component({
    template: `<button (click)="click($event)"`
})
export class ClickComponent {
    click = new HostEmitter<MouseEvent>()

    @Effect()
    handleClick(state: State<AppComponent>) {
        return state.click.subscribe(event => console.log(event))
    }
}

Two-way binding

Two-way binding is just syntactic sugar, so everything works as you would expect it to.

@Component()
export class CountComponent {
    @Input()
    count = 0

    @Output()
    countChange = new HostEmitter(true)

    @Effect("count")
    resetCount(state: State<AppComponent>) {
        return changes(state.count).pipe(
            delay(1000),
            mapTo(0)
        )
    }

    @Effect("countChange")
    emitCount(state: State<AppComponent>) {
        return changes(state.count)
    }
}

@Component({
    template: `<app-count [(count)]="count"></app-count>`
})
export class AppComponent {
    count = 10

    @Effect()
    handleCountChange(state: State<AppComponent>) {
        return state.count.subscribe(count => console.log(count))
    }
}

Queries

In Angular we can get a reference to child components, directives and providers of a view by using queries. There are four types, each available at different stages of the component lifecycle.

Query	Type	Lifecycle
ContentChild	any	OnInit, AfterContentInit
ContentChildren	QueryList	AfterContentInit
ViewChild	any	OnInit, AfterViewInit
ViewChildren	QueryList	AfterViewInit

In Angular Effects, we wait for the first change detection cycle before inspecting the value of view queries. Effects that depend on view queries should be deferred by configuring the @Effect() decorator with whenRendered: true. Static or dynamic queries make no difference here.

For example, given a child component we would like to query:

@Component()
export class ChildComponent {}

We can read the query within our deferred effects.

@Component({
    template: `
        <app-child *ngFor="let item of items></app-child>
    `
})
export class AppComponent {
    items = [1, 2, 3]

    @ViewChild(ChildComponent)
    viewChild: ChildComponent

    @ViewChildren(ChildComponent)
    viewChildren: QueryList<ChildComponent>

    @Effect({ whenRendered: true })
    logQueries(state: State<AppComponent>) {
        return latest(state).subscribe(({ viewChild, viewChildren }) => {
            console.log(viewChild)
            console.log(viewChildren.length)
        })
    }
}

TIP: The above example works for @ContentChild() and @ContentChildren() too

QueryList is a bit tricky to work with. You need to be aware that once the value has been attached to the component, you must additionally subscribe or switchMap to the query list changes observable to see any changes in view or content children. A small utility function can be written to make it easier:

function queryList<T extends QueryList<any>>(source: Observable<T>): Observable<T> {
    return source.pipe(
        switchMap(queryList =>
            queryList.changes.pipe(
                startWith(queryList)
            )
        )
    )
}

Then use it with state

queryList(state.viewChildren).subscribe(viewChildren => console.log(viewChildren))

Adapt your thinking

There's a lot to digest here. The good news is that you can take an incremental approach to adapting your existing applications with Angular Effects. As with RxJS, use what you know and take things one step at a time as you need them.

Speaking of adapters, the next article will explain how you can use effect adapters to write even more concise and expressive Angular Effects. This will also cover integration with global state stores, such as NgRx.

Thanks for reading!

Next in this series

Part I: Introducing Angular Effects
Part II: Getting started with Angular Effects
Part III: Thinking reactive with Angular Effects (You are here)
Part IV: Extending Angular Effects with effect adapters
Part V: Exploring the Angular Effects API
Part VI: Deep dive into Angular Effects

Getting started with Angular Effects

Michael Muscat — Mon, 02 Mar 2020 19:11:30 +0000

Angular Effects is a reactive state management solution for Angular. This article explains the initial setup and basic process for adding effects to your application.

This is part II in a series on Reactive State in Angular. Read Part I: Introducing Angular Effects

Installation

Angular Effects is available on NPM.

npm install ng-effects

Alternatively, you can download the source from Github.

Peer Dependencies

Angular Effects is compatible with Angular 9.0.0+ and RxJS 6.5+.

Usage

Effects are defined by annotating component methods with the @Effect() decorator.

@Component()
export class AppComponent {
    @Effect()
    myAwesomeEffect() {
        // Return an observable, subscription or teardown logic
    }
}

The example above is the minimum code necessary for a valid effect, but it won't do anything until we connect it.

Host effects and effect services

You can define effects on any component, directive or module. For brevity I will refer to these collectively as components. Effects can also be defined in injectable services.

@Injectable()
export class AppEffects {
    @Effect()
    myAwesomeEffect() {
        // Return an observable, subscription or teardown logic
    }
}

Effects defined directly on components are referred to as "host" effects, whereas services that provide effects are referred to as "effect services". This distinction is important when connecting effects.

Connecting effects

For every component we want to run effects on, there is some wiring involved.

First we must provide the Effects token in the providers array for each component that has effects.

@Component({
    providers: [Effects]
})

By providing this token the component can now be "connected". Also add any effect services that should be connected.

@Component({
    providers: [Effects, AppEffects]
})

The next step is to inject the Connect function and call it from the constructor of the component.

@Component({
    providers: [Effects, AppEffects]
})
export class AppComponent {
    author?: Author
    books: Book[]

    constructor(connect: Connect) {
        this.books = []          // Should initialize variables
        this.author = undefined  // even if they are undefined.

        connect(this)            // Must always be called in the constructor
    }

    @Effect()
    myAwesomeEffect() {
        // Return an observable, subscription or teardown logic
    }
}

NOTE: connect() should be called after initializing class fields with default values.

As seen here, components can utilise both host effects and effect services at the same time. Mix and match as you see fit.

Anatomy of an effect

Now that we know how to create and initialize effects in our components, it's time to explore what goes inside. Each effect method is a factory that is only called once, each time the component is created. What we do inside each effect should therefore take into account the entire lifecycle of a component.

Depending on the configuration, the effect will either run:

the moment connect() is called; OR
immediately after the first change detection cycle (ie. when it has rendered).

The behaviour of each effect depends on its configuration and return value.

Arguments

For convenience, each effect receives three arguments. The same values can also be obtained by injecting HostRef<T> through the constructor.

Argument	Type	Description
state	`State<T>`	An object map of observable fields from the connected component.

The state object is the mechanism by which we can observe when a property on the component changes. There are two behaviors that should be observed before using it.

@Component()
export class AppComponent {
    count = 0

    @Effect()
    myAwesomeEffect(state: State<AppComponent>) {
        return state.count.subscribe(value => console.log(value))
    }
}

Output:
> 0

When subscribing to a property, the current state is emitted immediately. The value is derived from a BehaviorSubject, and is read only.

@Component()
export class AppComponent {
    count = 0

    @Effect()
    myAwesomeEffect(state: State<AppComponent>) {
        return state.count.subscribe(value => console.log(value))
    }

    @Effect("count")
    setCount() {
        return from([0, 0, 0, 10, 20])
    }
}

Output:
> 0
> 10
> 20

You might expect 0 to be logged several times, but here it's only logged once as state only emits distinct values.

Keep this in mind when writing effects. Helpful error messages will be shown when trying to access properties that cannot be observed (ie. they are missing an initializer or are not enumerable).

Argument	Type	Description
context	`Context<T>`	A reference to the component instance.

The second argument is the component instance itself. There are times when we want to simply read the current value of a property, invoke a method or subscribe to a value without unwrapping it from state first.

interface AppComponent {
    formData: FormGroup
    formChange: EventEmitter
}

@Injectable()
export class AppEffects {
    @Effect()
    myAwesomeEffect(state: State<AppComponent>, context: Context<AppComponent>) {
        return context
            .formData
            .valueChanges
            .subscribe(context.formChange)
    }
}

Effects can be used in a variety of ways, from a variety of sources. Angular Effects lets us compose them as we see fit.

Argument	Type	Description
observer	`Observable<T>`	An observable that is similar to `DoCheck`.

The last argument is one that should rarely be needed, if ever. It emits once per change detection cycle, as well as whenever an effect in the current context emits a value. Use this observable to perform custom change detection logic, or debug the application.

Return values

Unless modified by an adapter, each effect must return either an observable, a subscription, a teardown function, or void. The return value dictates the behavior and semantics of the effects we write.

Effect -> Observable

When we want to bind the emissions of an effect to one or more properties on the connected component, we do so by returning an observable stream.

@Component()
export class AppComponent {
    count = 0

    @Effect("count")
    incrementCount(state: State<AppComponent>) {
        return state.count.pipe(
            take(1),
            increment(1),
            repeatInterval(1000)
        )
    }
}

We can return observables for other reasons too, such as scheduling change detection independent of values changing, or when using adapters.

Effect -> Subscription

The semantics of returning a subscription is to perform side effects that do not affect the state of the component. For example, dispatching an action.

@Component()
export class AppComponent {
    count = 0

    @Effect()
    dispatchCount(state: State<AppComponent>) {
        return state.count.subscribe(count => {
            this.store.dispatch({
                type: "COUNT_CHANGED",
                payload: count
            })
        })
    }

    constructor(private store: Store<AppState>) {}
}

TIP: While good enough to illustrate this particular example, later we will see better ways to integrate global state patterns using effect adapters.

Effect -> Teardown function

Angular Effects can be written in imperative style as well. This is particularly useful when doing DOM manipulation.

@Component()
export class AppComponent {
    @Effect({ whenRendered: true })
    mountDOM(state: State<AppComponent>) {
        const instance = new MyAwesomeDOMLib(this.elementRef.nativeElement)

        return () => {
            instance.destroy()
        }
    }

    constructor(private elementRef: ElementRef) {}
}

Effect -> void

If nothing is returned, it is assumed we are performing a one time side effect that does not require any cleanup.

Configuration

The last part of the effect definition is the metadata passed to the decorator.

@Component()
export class AppComponent {
    @Effect({
        bind: undefined,
        assign: undefined,
        markDirty: undefined,
        detectChanges: undefined,
        whenRendered: false,
        adapter: undefined
    })
    myAwesomeEffect() {}
}

Each option is described in the table below.

Option	Type	Description
bind	string	When configured, maps values emitted by the effect to a property of the same name on the host context. Throws an error when trying to bind to an uninitialised property. Default: `undefined`
assign	boolean	When configured, assigns the properties of partial objects emitted by the effect to matching properties on the host context. Throws an error when trying to bind to any uninitialised properties. Default: `undefined`
markDirty	boolean	When set to true, schedule change detection to run whenever a bound effect emits a value. Default: `true` if bind or apply is set. Otherwise `undefined`
detectChanges	boolean	When set to true, detect changes immediately whenever a bound effect emits a value. Takes precendence over `markDirty`. Default: `undefined`
whenRendered	boolean	When set to true, the effect deferred until the host element has been mounted to the DOM. Default: `false`
adapter	Type	Hook into effects with a custom effect adapter. For example, dispatching actions to NgRx or other global state stores. Default: `undefined`

We'll explore these options and more in future articles.

You already know how to write effects

If you're using observables and connecting them to async pipes in your template, then you already know how to use this library. Angular Effects are easier to write, and even easier to use. It's type safe. It's self managed. It lets components focus on the things they are good at: rendering views and dispatching events.

TIP: Angular Effects can also be used to compose global effects with component scope (including route components). Don't forget that it works with modules and directives too.

Next time we'll look at how some common Angular APIs can be adapted to work with Angular Effects for fun and for profit.

Thanks for reading!

Next in this series

Part I: Introducing Angular Effects
Part II: Getting started with Angular Effects (You are here)
Part III: Thinking reactive with Angular Effects
Part IV: Extending Angular Effects with effect adapters
Part V: Exploring the Angular Effects API
Part VI: Deep dive into Angular Effects

Reactive State in Angular: Introducing Angular Effects

Michael Muscat — Sun, 01 Mar 2020 07:55:22 +0000

Angular is a powerful framework. It has observables, it has TypeScript, it has dependency injection. Great! But how do I manage state? We are left to figure this out for ourselves.

There are some great libraries for state management out there, such as NgRx. But these only deal with global state. Things can become messy once we try to glue them to our components.

What I need is state management for components. I want it to connect to global state, and I want it to be easy to use. I don't want it to be cluttered with boilerplate. I want my templates to be synchronous, no async pipes. And I don't want to manage subscriptions.

Many attempts have been made at such solution, but nothing satisfying has emerged to date. If you've entertained these thoughts so far, let's look at some code.

Introducing Angular Effects: Reactive extensions for Angular

@Component({
    selector: "app-root",
    template: `
        <div>Count: {{count}}</div>
    `,
    providers: [Effects],
})
export class AppComponent {
    @Input()
    count: number = 0

    constructor(connect: Connect) {
        connect(this)
    }

    @Effect("count")
    incrementCount(state: State<AppComponent>) {
        return state.count.pipe(
            take(1),
            increment(1),
            repeatInterval(1000)
        )
    }
}

This library is a set of reactive primitives that fills in the missing blanks in Angular's reactive API. It makes it both possible and easy to observe and react to the state of your components. Here's a few highlights:

You can observe when any property on the component changes
This lets you write fully reactive applications
Subscriptions are automatically cleaned up when the component is destroyed
You can pipe inputs and outputs
You can extract stateful behaviors into services
You can ditch async pipes
You might not need lifecycle hooks
It works with or without zones
You can compose all of your observable sources
You can extend it with adapters
Change detection "just works", and you can fine tune it
No components are harmed when using this library (composition over inheritance)

Why you should use Angular Effects

The Angular Effects Lifecycle

Simpler templates

A large source of complexity in Angular is how async data is handled in templates. Some common problems are:

Default values: Showing default values with async bindings

@Component({
    template: `
        <ng-container *ngIf="count$ | async as count">
            {{ count }}
        </ng-container>
    `
})
export class AppComponent {
    count$ = timer(1000).pipe(
        mapTo(10),
        startWith(0), // default value
    )
}

With Angular Effects component templates are always synchronous.

@Component({
    template: `
        {{ count }}
    `
})
export class AppComponent {
    count = 0

    @Effect("count")
    setCount(state: State<AppComponent>) {
        return timer(1000).pipe(
            mapTo(10)
        )
    }
}

Multiple subscribers: Binding async sources multiple times in different parts of the template

Because every subscriber triggers the entire chain of operations in an observable, we have to be careful not to accidentally trigger certain effects, such as http requests, multiple times.

@Component({
    template: `
        <button *ngIf="count$ | async as count">{{ count }}</button>
        <a *ngIf="count$ | async as count">{{ count }}</a>
    `
})
export class AppComponent {
    count$ = this.http.get("/getCount").pipe(
        startWith(0)
    )

    constructor(private http: HttpClient) {}
}

When this component is rendered, two http calls are made, one for each subscription. This can be mitigated by moving the async pipe to a common ancestor

<ng-container *ngIf="count$ | async as count">
    <button>{{ count }}</button>
    <a>{{ count }}</a>
</ng-container>

Or by using the share operator

export class AppComponent {
    count$ = this.http.get("/getCount").pipe(
        startWith(0),
        share()
    )

    constructor(private http: HttpClient) {}
}

However it's not always possible to do the former, and can be difficult to know where or when to use the latter.

With Angular Effects, we only subscribe once.

@Component({
    template: `
        <button>{{ count }}</button>
        <a>{{ count }}</a>
    `
})
export class AppComponent {
    count = 0

    constructor(private http: HttpClient) {}

    @Effect("count")
    getCount(state: State<AppComponent>) {
        return this.http.get("/getCount")
    }
}

Async composition: Templates with nested async bindings dependent on input values

@Component({
    template: `
        <ng-container *ngIf="author$ | async as author">
            <ng-container *ngIf="author">
                <div *ngFor="let book of books$ | async">
                    <p>Author: {{ author.name }}</p>
                    <p>Book: {{ book.title }}</p>
                </div>
            </ng-container>
        </ng-container>
    `
})
export class AppComponent {
    @Input()
    authorId = 1

    author$ = this.getAuthor()
    books$ = this.getBooks()

    getAuthor() {
        this.author$ = this.http.get(`/author/${this.authorId}`)
    }

    getBooks() {
        this.books$ = this.http.get(`/books?authorId=${this.authorId}`)
    }

    ngOnChanges(changes) {
        if (changes.authorId) {
            this.getAuthor()
            this.getBooks()
        }
    }
}

One problem with this code is that books$ is not fetched until author$ has resolved due to it being nested inside an ngIf in the template. This could be resolved by combining these observables into a single data source, but this can be difficult to manage. We'd like to subscribe to individual data streams separately and without blocking the template.

With Angular Effects we can subscribe to streams in parallel and render them synchronously.

@Component({
    template: `
        <ng-container *ngIf="author">
            <div *ngFor="let book of books">
                Author: {{ author.name }}
                Book: {{ book.title }}
            </div>
        </ng-container>
    `
})
export class AppComponent {
    @Input()
    authorId: number

    author?: Author = undefined

    books: Book[] = []

    @Effect("author")
    getAuthor(state: State<AppComponent>) {
        return state.authorId.pipe(
            switchMap(authorId => this.http.get(`/author/${authorId}`))
        )
    }

    @Effect("books")
    getBooks(state: State<AppComponent>) {
        return state.authorId.pipe(
            switchMap(authorId => this.http.get(`/books?authorId=${authorId}`))
        )
    }
}

You might not need lifecycle hooks

We can observe the state of a component and write effects around them. Here's why you probably don't need lifecycle hooks.

`OnInit`

Purpose: To allow the initial values of inputs passed in to the component and static queries to be processed before doing any logic with them.

Since we can just observe those values when they change, we can discard this hook.

`OnChanges`

Purpose: To be notified whenever the inputs of a component change.

Since we can just observe those values when they change, we can discard this hook.

`AfterContentInit`

Purpose: To wait for content children to be initialized before doing any logic with them.

We can observe both @ContentChild() and @ContentChildren() since they are just properties on the component. We can discard this hook.

`AfterViewInit`

Purpose: To wait for view children to be initialized before doing any logic with them. Additionally, this is the moment at which the component is fully initialized and DOM manipulation becomes safe to do.

We can observe both @ViewChild() and @ViewChildren() since they are just properties on the component. For imperative DOM manipulation, effects can be deferred until the component has rendered. We can discard this hook.

`OnDestroy`

Purpose: To clean up variables for garbage collection after the component is destroyed and prevent memory leaks.

Since every effect is a sink for observables, we won't need this hook very often.

Observable host listener and template events

Angular Effects provides an extension of EventEmitter called HostEmitter that should be used as a drop in replacement. HostEmitter makes it possible to observe HostListener, and also makes it easier to work with Angular Effects in general.

For example, here's a button that uses HostListener to observe click events and pass them through if it's not disabled.

@Component({
    selector: "button[ngfx-button]"
})
export class ButtonComponent {
    @Input()
    disabled = false

    @HostListener("click", ["$event"])
    clicked = new HostEmitter<MouseEvent>()

    @Output()
    pressed = new HostEmitter<MouseEvent>()

    @Effect("pressed")
    handleClick(state: State<AppComponent>) {
        return state.clicked.pipe(
            withLatestFrom(state.disabled, (event, disabled) => disabled ? false : event),
            filter(Boolean)
        )
    }
}

Here's a component using the button, observing its events from the template and disabling the button when it is clicked.

@Component({
    template: `
        <button ngfx-button [disabled]="buttonDisabled" (pressed)="buttonPressed($event)">
            Click me
        </button>
    `
})
export class AppComponent {
    buttonDisabled = false
    buttonPressed = new HostEmitter<MouseEvent>()

    @Effect("buttonDisabled")
    disableButton(state: State<AppComponent>) {
        return state.buttonPressed.pipe(
            mapTo(true)
        )
    }
}

Renderless components

Renderless components were popularised by Vue as components without a view. Behavior without a template. We know them as mixins. But it isn't easy to use mixins in Angular. Angular Material shows us just how many hoops we have to jump through.

Angular Effects finally makes this possible, and easy. It makes it possible by extracting all stateful behavior from a component, into an injectable service.

Let's see how it makes it easy.

@Component({
    selector: "button[ngfx-button]"
})
export class ButtonComponent {
    @Input()
    disabled = false

    @HostListener("click", ["$event"])
    clicked = new HostEmitter<MouseEvent>()

    @Output()
    pressed = new HostEmitter<MouseEvent>()

    @Effect("pressed")
    handleClick(state: State<AppComponent>) {
        return state.clicked.pipe(
            withLatestFrom(state.disabled, (event, disabled) => disabled ? false : event),
            filter(Boolean)
        )
    }
}

We can extract the effect into a service. We'll also tweak things a bit to get rid of the HostListener.

interface ButtonLike {
    disabled: boolean
    pressed: HostEmitter<MouseEvent>
}

function registerOnClick(elementRef, renderer) {
    return function(handler) {
        return renderer.listen(elementRef.nativeElement, "click", handler)
    }
}

@Injectable()
export class Button {
    constructor(private elementRef: ElementRef, private renderer: Renderer2) {}

    @Effect("pressed")
    handleClick(state: State<ButtonLike>) {
        return fromEventPattern(registerOnClick(this.elementRef, this.renderer)).pipe(
            withLatestFrom(state.disabled, (event, disabled) => disabled ? false : event),
            filter(Boolean)
        )
    }
}

This is our renderless button. All the consumer has to do to use it is implement the interface, provide the token and write the template.

@Component({
    selector: "button[ngfx-button]",
    providers: [Effects, Button]
})
export class ButtonComponent implements ButtonLike {
    @Input()
    disabled = false

    @Output()
    pressed = new HostEmitter<MouseEvent>()

    constructor(connect: Connect) {
        connect(this)
    }
}

Previous examples have omitted the wiring necessary to make effects run. To explain it here briefly, each component needs to provide Effects at a minimum, and then call connect() in the constructor after properties have been initialized. Add more effects by adding them to providers.

Now we have a reusable Button "trait" that can be used to build different types of buttons, or composed with other effects to do something more interesting. For example, a select component could be composed out of Button, Select, Option and Dropdown traits.

Angular Effects gives you renderless components for Angular.

Reactive applications

We have only scratched the surface of what can be done with Angular Effects. In future installments I will take you through a deep dive of the API, how it works, and more examples on how it can be used to make better reactive applications using Angular.

You can get started with Angular Effects today to make your applications more reactive. Feedback welcome. With Angular Effects we can write truly reactive applications from top to bottom.

Thanks for reading!

npm install ng-effects

Acknowledgements

I couldn't have made this library without the excellent research and demos presented by Michael Hladky and others in this RFC.

DEV Community: Michael Muscat

Playing with Providers

1. inject()

2. Injection Context

3. Type Safety

Caveats

Exploring the Angular Effects API

Multiple bindings

Assignment bindings

Module effects

Special injection tokens

HostRef

Two-way observable state: Renderless select

Experimental features

Zoneless change detection

Global connect hook

Connect API

Diving deep into Angular

Next in this series

Extending Angular Effects with effect adapters

Integrating Angular Effects with @ngrx/store

Implementing a shouldComponentUpdate lifecycle hook

More effective components

Next in this series

Thinking reactive with Angular Effects

How to use Angular Effects

Input bindings

Output bindings

A note on ExpressionChangedAfterItHasBeenCheckedError

Host bindings

Host listeners

Template listeners

Two-way binding

Queries

Adapt your thinking

Next in this series

Getting started with Angular Effects

Installation

Peer Dependencies

Usage

Host effects and effect services

Connecting effects

Anatomy of an effect

Arguments

Return values

Configuration

You already know how to write effects

Next in this series

Reactive State in Angular: Introducing Angular Effects

Why you should use Angular Effects

Simpler templates

Default values: Showing default values with async bindings

Multiple subscribers: Binding async sources multiple times in different parts of the template

Async composition: Templates with nested async bindings dependent on input values

You might not need lifecycle hooks

OnInit

OnChanges

AfterContentInit

AfterViewInit

OnDestroy

Observable host listener and template events

Renderless components

Reactive applications

Acknowledgements

Further Reading

Next in this series

1. `inject()`

Integrating Angular Effects with `@ngrx/store`

Implementing a `shouldComponentUpdate` lifecycle hook

A note on `ExpressionChangedAfterItHasBeenCheckedError`

`OnInit`

`OnChanges`

`AfterContentInit`

`AfterViewInit`

`OnDestroy`