The non-coalesced component has three consequetive heavy computations in the template whilest the coalesced component only has to do the same computation once in order to complete the same job.

**Event Bubbling of smae event on multiple elements**


The wanted bevavior should execute change detection only once per component.

- As operator in the compomponent class

- **explicitly** e.g. `Number(string)` coercres a string to a number

- **implicitely** e.g. `!!string` coerces a string to a boolean

In general when we apply those techniques our code base starts to maintain repetative patterns which either bloten up the codebase or just makes it harder to read.

Because we receive the value from an input the type is always string. We have to care every time the when we want to pass the value to get a propper number type of it.

Since then, developers where encurraged to match the types exaclty. This especially needs attention when it comes to templates.

The included helpers can be used whenever coercing is needed to obtain a propper value.

RxAngular also spotted a often used pattern of cosercing.

When trying out the different reactive architectures we realized for a nice to use mix of reactive and imperative programming we needed to accept statis values as well as Observables on many places.

In the following we will sketch some usecases where coercing operators can be used.

The order (first, second, thrid) is determined by the level of "nesting" of the streams.

The question to answer here is if we receive a series of observables, how do we deat with all the streams?

Should we merge them all togeather aor should we stop the previouse and start the new one? Or should we even queu them up?

Here we apply the `switchAll` operator to unsubscribe the previouse observable and subscribe to the new one.

by using the `coerceAllFactory` function we can compose this pattern with less code and still have the option to decide on the way of compostion.

Angulars change detection is pull-based and implicit.

`@rx-angular/cdk` comes preconfigured with two sets of strategies.

As a fallback for the migration process or comparison testing, Angulars default change detection behaviour is also provided as a strategy.

By default, RxAngular render strategies are preconfigured in a way they are still way more performant than native Angular but focusing on being as non-breaking as possible.

Configurations are done with Angular best practies and based on `InjectionToken`'s.

> As all configurtion are controlled by `RxStrategyProvider`, an Angular service, we can apply

profidedIn: 'root',

If we apply this concepts to our change detection mechanics we can directly apply changes where they are needd and skip nearly all the unnessecary work.

Users constantly interract with our site and this means if our main thread is busy, they can't interact whit the page. The events like scroll or click will get delayed until the main thread is unblocked from work again and can process those interactions.

concole.log('work done!');

The image shows that all AnimatioFrame events end up in the same task.

This number is called frame budget and measured in milliseconds. As a result of this technique we're getting prioritized user-centric scheduling behaviours.

What concurrent scheduling does under the hood is is cunking up work in cycles of scheduling, prioritization and execution based on different settings.






In many cases, this leads to heavy refactorings to get the performance flaw out or even end up in situations where we can't fix the performance issues.

insertCeature(): void {

const anonymusCat = deleteProp(cat, 'name');

const catWithname = patch(cat, { name: 'Fluffy' });