Forem: Younes Jaaidi

Vitest's 4.1 New "Fast-Forward" Mode Skips Timer Delays Instantly

Younes Jaaidi — Wed, 18 Mar 2026 13:42:46 +0000

An important property of tests is that they should be composable.

Here is an example. Say you have a search component with a 300ms debounce. You've already tested the debounce behavior itself — "does it wait 300ms before firing?" — in a dedicated test. Now every other test that involves this component shouldn't care whether the debounce is there or not. Change the delay from 300ms to 500ms? Only the debounce test should break. Not the 15 other tests that just happen to type into that search field.

Let's look at what this problem looks like, then at different approaches to solving it.

The Challenge with Manual Fake Timers

The classic approach of fake timers in manual mode breaks composability by coupling all the tests to the debounce.

vi.useFakeTimers();

mountCookbookSearch();

await page.getByLabel('Keywords').fill('Marmicode');

await vi.advanceTimersByTimeAsync(310);

await expect
  .element(page.getByRole('heading'))
  .toHaveTextContent('Angular Testing Cookbook | Marmicode');

This test knows about the 300ms debounce (note the 310ms — time is not a precise science 😉). Change the debounce to 500ms and this test breaks — even though it's testing search results, not timing.
You could use vi.runAllTimersAsync() instead to flush all pending timers without specifying a duration. That's less coupled to the exact value, but the test still knows it needs to deal with timers at all. And manual mode freezes all timers — including framework internals like Angular's synchronization or React's scheduler fallbacks — which can require deep knowledge of framework internals just to get your test to run.

Let's fix this.

Solution #1 — Real Time and Polling

If you're using Vitest Browser Mode, DOM interactions using the page API and assertions such as expect.element poll. They respectively retry until the element is found or the assertion passes — or until the timeout is reached.

mountCookbookSearch();

await page.getByLabel('Keywords').fill('Marmicode');

// This will keep retrying until the debounce hits and the
// "Angular Testing Cookbook" is the only cookbook remaining.
await expect
  .element(page.getByRole('heading'))
  .toHaveTextContent('Angular Testing Cookbook | Marmicode');

No fake timers. No manual time advancement. The test just waits for the heading to appear.

This works, and it's composable but it has a cost: the test is as slow as the debounce.

Solution #2 — Dynamic Timing Configuration

Another approach is to make the delay configurable and override it in tests.

This is composable and fast. It's often the best approach when you control the code. I cover this pattern in detail in my Controlling Time in Tests cookbook chapter.

Solution #3 — "Fast-Forward" Mode

Vitest 4.1 introduces a way to control how fake timers automatically advance time vi.setTimerTickMode('nextTimerAsync') — what I call "fast-forward" mode.
Unlike manual fake timers where you have to call vi.advanceTimersByTimeAsync(310) and know the delay, "fast-forward" mode advances the clock on its own, as quickly possible and as far as necessary. You don't need to know the delay value. You don't need to manually advance anything.

vi.useFakeTimers().setTimerTickMode('nextTimerAsync'); // 👈

mountCookbookSearch();

await page.getByLabel('Keywords').fill('Marmicode');

await expect
  .element(page.getByRole('heading'))
  .toHaveTextContent('Angular Testing Cookbook | Marmicode');

The 300ms debounce is skipped instantly. Change it to 5 seconds — the test still passes in milliseconds. ✨

It's composable (the test doesn't know about the delay), and it's fast (no real waiting).

⚠️ Make sure you restore real timers.

Special thanks to Andrew and Vladimir

"Fast-forward" mode exists thanks to Andrew Scott from the Angular team — alongside Vladimir Sheremet from the Vitest team.

Going Deeper

I cover the full decision tree — manual mode, "fast-forward" mode, dynamic timing configuration, and their trade-offs — in the Controlling Time in Tests chapter of my Angular Testing Cookbook. Step-by-step recipes included. 👨🏻‍🍳

I'm Younes Jaaidi, Angular GDE & Nx Champion. I help teams write tests that survive refactoring through a video course, a 3-day hands-on workshop, and a free cookbook.

The Missing Ingredient for Angular Template Code Coverage and Future-Proof Testing

Younes Jaaidi — Mon, 18 Nov 2024 15:37:53 +0000

TL;DR: Turn on Ahead-Of-Time (AOT) compilation for your Angular tests to get accurate template code coverage, faster test execution, production-symmetry, and future-proof tests.

The option is already available for Vitest users and will soon be available for Karma and Jest (experimental builder) users.

😧 What's wrong with JIT?

Whether you are using Karma, Jest, or Vitest, you are probably using Just-In-Time (JIT) compilation for your Angular tests, as until recently, it was the only available option.

The problem is that JIT has a few significant downsides:

Code coverage is not accurate as the template is not taken into account.
It is slower as the tests compile the templates on the fly.
It is not future-proof as Angular has reached the limits of JIT compatibility. By design, some features are simply impossible to implement with JIT.
It is not symmetrical with the production environment, where AOT is used.

⏰ Why now?

Since Angular 8 and the introduction of IVy, the Angular compiler has started transforming templates into instructions. Among many other benefits, this also meant that code coverage tools could map these instructions to the template and compute the code coverage accordingly.

Theoretically, it has been possible to produce code coverage by running tests with AOT since Angular 8, but the option was not available in Karma or Jest. It has only been possible to enable AOT for testing since Vitest support for Angular was added by the Analog team.

As of November 2024:

Vitest is the only option that supports AOT compilation.
There are open PRs for Karma and Jest Experimental Builder to support AOT.

🎁 Other Benefits of AOT Testing

⚡️ Faster Test Execution

Whether you are using JIT or AOT, components will end up being compiled at some point. The main difference is that with AOT, the compilation is done once and can be cached, while with JIT, each test module might end up recompiling components.

This means that even if the transform phase is a bit slower with AOT, the overall test execution time will be faster. The numbers I've seen indicate around 20% faster execution, but this will depend heavily on the structure of your tests and the System Under Test.

👯 Production-Symmetry

We generally want our tests to be as symmetric as possible to the production environment to increase confidence. This is often challenging as it balances against other properties like the speed of the tests, the size of the System Under Test, or predictability.

The interesting aspect of AOT is that it improves production-symmetry without harming other properties. Using AOT, you will gain more confidence and achieve behavior that is closer to production.

🔮 Future-Proof Tests

More importantly, JIT has reached its limits and is becoming a liability for Angular. For instance, some Angular features are simply not supported in JIT (e.g. Deferrable Views). Other potential features from the Angular roadmap, like selectorless components, will probably be impossible to use with JIT.

Actually, since Angular's Signal Inputs (and similar functional APIs), JIT already requires some minimal transforms to work.

By switching to AOT, you are making your tests future-proof, ready to benefit from any innovation, and prepared for whatever the future holds for JIT.

🤔 Drawbacks

🪄 Dynamic Component Constructs Should Be Avoided

By turning on AOT, some techniques that rely on dynamic constructs will break.

For instance, such usage will not work anymore:

// 🛑 This is broken with AOT.
const fixture = render(`<app-button/>`, { imports: [Button] });

function render(template, { imports }) {
  @Component({
    template,
    imports,
  })
  class TestContainer {}

  return TestBed.createComponent(TestContainer);
}

However, bypassing the AOT compilation is still possible (⚠️ for now ️⚠️):

function render(template, { imports }) {
  @Component({
    jit: true,
    template,
    imports,
  })
  class TestContainer {}

  return TestBed.createComponent(TestContainer);
}

My advice is to avoid such constructs as much as possible and prefer creating test-specific components when needed, even though it might be a bit more verbose. In the future, the Angular team could provide alternatives that are both AOT-compatible and less boilerplat-y.

🦦 Shallow Testing is More Challenging

While Shallow Testing should not be your primary testing strategy as it is also less production-symmetric, it is still a useful technique to have in your toolbox.

With AOT, it is currently impossible to override a component's imports using TestBed#overrideComponent.

The workaround is to override the component's dependencies at the module level using the testing framework's API and replace components with their test doubles.

For example, with Vitest:

// app.cmp.spec.ts
vi.mock('./street-map.cmp', async () => {
  return {
    StreetMap: await import('./street-map-fake.cmp').then(
      (m) => m.StreetMapFake
    ),
  };
});

// street-map-fake.cmp.ts
@Component({
  selector: 'app-street-map',
  template: 'Fake Street Map',
})
class StreetMapFake implements StreetMap {
  // ...
}

While this temporary workaround is AOT-compatible, it comes with a cost:

It is less readable and more verbose.
"Mocking" (or providing test doubles) at the module level is less granular and can be less predictable.
It is highly coupled to the testing framework you are using.

For now, I would recommend using JIT for Shallow Tests until TestBed#overrideComponent supports AOT or until the Angular team provides a better alternative. You can achieve this by using a separate configuration for Shallow Tests that use JIT for tests matching a specific pattern like *.jit.spec.ts.

👨🏻‍🍳 Taking Vitest with AOT for a Spin

1. Set up Vitest

For Angular CLI users, use Analog's schematic.
For Nx users, choose the vitest option when generating an application or library (available since Nx 20.1.0).

2. Enable AOT

Locate the vite.config.js file and turn on AOT by setting Angular's plugin jit option to false:

export default defineConfig({
  ...
  plugins: [
    angular({ jit: false }),
    ...
  ],
  ...
});

📈 Configure Code Coverage

We have the option to use either istanbul or native v8 for code coverage. For some reason, still under investigation, Vitest coverage remapping fails when using v8. The solution is to fall back to using istanbul instead.

1. Install `@vitest/coverage-istanbul`

Make sure you install the Vitest Istanbul version that matches Vitest's major version

npm install -D @vitest/coverage-istanbul

2. Choose `istanbul` as your coverage provider

Update the vite.config.mts to enable coverage using Istanbul:

export default defineConfig({
  ...
  test: {
    ...
    coverage: {
      provider: 'istanbul',
    },
  },
});

🎬 Watch it in Action

You can now run the tests:

nx test my-app --coverage --ui --watch
# or
ng test --coverage --ui --watch

then click on the coverage icon and admire the template's code coverage. 🤯

(you will also find the coverage report in the coverage folder)

Note that the coverage is computed based on the instructions generated by the compiler, which means that:

It will even work for structural directives.

Now, guess what!?

The coverage also works for inline templates! 🚀

☢️ Mind the Code Coverage Trap

While code coverage is a useful tool, it should be used wisely. Keep it as an indicator, not a rigid goal.

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.

-- Charles Goodhart

In other words, when a measure becomes a target, it ceases to be a good measure.

I'd add that the simplest metrics are often the most misleading.

🚀 What's Next?

Karma users will soon be able to enable AOT with a simple flag.

Jest users have three options:

Recommended: Migrate to Vitest. (📻 stay tuned as I'll soon be sharing the smoothest migration path)
Use the experimental builder with AOT.
Wait for jest-preset-angular AOT support.

Vitest users can enjoy the benefits of AOT right now. 🎉

📚 Additional Resources

💻 Demo Repo
📝 Angular Ahead-Of-Time (AOT) Compiler Docs
📝 Vitest Docs
📝 Analog's Docs on Vitest

👨🏻‍🏫 Pragmatic Angular Testing Video Course is Here!

If you are tired of bugs, or high-maintenance tests that break at each refactor, my video course, Pragmatic Angular Testing, is here to help!

Learn practical, reliable testing strategies to keep your Angular apps stable and maintainable. (Now 50% off for a limited time!)

Managing RxJS Traffic with Signals and Suspensify

Younes Jaaidi — Mon, 10 Jul 2023 12:31:20 +0000

Will Signals replace RxJS?

TL;DR: No! Not totally.

While Angular is not the first framework to implement Signals, it is The framework where developers rely most on RxJS. This raises many interrogations on the future of RxJS in the Angular ecosystem and whether Signals will partially or totally replace RxJS.

What we are facing here is what I like to call the Spoon-and-Fork situation which we are used to in the software world.

Considering that spoons probably appeared before forks, the day forks appeared, some might have seen them as a replacement for spoons. When they tried them on mashed potatoes... until the day they were served soup.

Each time two solutions overlap in solving some specific problem, the last one released can be hastily and mistakenly considered as a total replacement of the older one.

RxJS provides unequaled ways of managing time-related manipulations of push-based data streams like buffering, throttling, retrying, exponential backoff, or orchestration through flattening strategies.
On the other hand, it is not necessarily the best fit for describing the reactive graph between a value that we change and the Angular views using it.

That is where Signals come into play and simplify the propagation of changes to the views.

If you want to learn more about Signals, I highly recommend this blog post by my friend Tomas Trajan, and also my own blog post 😅 if you want a quick deep dive in some internals

RxJS has a time dimension which is very interesting but it comes with a cost, the cost of using RxJS operators (i.e. map) and Angular pipes (i.e. async & push) to “push” the changes to the view.

Signals on the other hand don’t have any stream-awareness or time-awareness but they are pretty good at building a reactive graph and propagating changes from the value change to the view and through the transformations made by "computed" signals.

✨ Let Signals shine!

While there is clearly some overlap between Signals and RxJS, let’s make each one of them shine where it fits best.
Unless you don’t care about the download/upload progress, retry capabilities, and anything time-related, you might not need RxJS, but most of the time we'll want to care about these things... except at the view level.

What matters most at the component/view level is the current state. A component lives in the present, and Signals are a representation of the present.

Let's just bridge the gap and "project" the observable's present state to a Signal using toSignal() function, and let's go out for a beer, right?

But wait!

What happens if there is an error?

Also, how do we know if the observable emitted a value or not yet?

And what about an observable that emits multiple values, how can we know if it did complete or not?

♻️ Spinner vertigo

Suppose that we are fetching data from a remote service. Let’s convert the Observable to a Signal and forward it to a child component.

@Component({
  …
  template: `<mc-recipe [recipe]=”recipe()”/>`
})
class MyCmp {
  recipe = toSignal(this.getRecipe());

  getRecipe() {
    return of('🍔').pipe(delay(1000));
  }
}

That’s when we might hit a common typing issue:

error TS2322: Type 'string | undefined' is not assignable to type 'string'

The child component is expecting a string as an input but the current default behavior of toSignal() is to not require the Observable to emit a value before the Signal is read. It falls back on the default initial value which is undefined and that can be customized using the initialValue option.

So, we can either force people to eat pizza and empty strings:

recipe = toSignal(this.getRecipe(), {initialValue: '🍕'});

Or stick to the default behavior…

recipe = toSignal(this.getRecipe());

…then handle this in the template and show a spinner until the data is ready.

<mc-spinner *ngIf="!recipe()"/>
<mc-recipe *ngIf="recipe() as recipeValue" [recipe]="recipeValue" />

Now, what if for some chaotic reason, the Observable returned by getRecipe() emits a null or undefined value or an empty string?

In that case, the spinner would just keep spinning because we can’t make any difference between the pending status and an emitted value that matches the initial value.

This also raises, the problem of using *ngIf + as to narrow the type and undergo the boolean coercion as a side effect.

💥 “Oups! Your valid data is invalid.”

Errors happen and we might want to handle them 😉

In fact, if our Observable errors, the Signal (and those computed from it) will simply throw the error when read.
As Signals will mostly be read in the template, there is no convenient way of handling the error.

The first solution that one might think of is using RxJS’s catchError() and setting the error in another signal as a side effect.

@Component({
  …
  template: `
    <div *ngIf="error()">Oups! Something went wrong.</div>
    <mc-recipe *ngIf="recipe() as recipeValue" [recipe]="recipeValue" />
  `,
})
export class AppComponent {
  error = signal(null);
  recipe = toSignal(
    this.getRecipe().pipe(
      catchError((error) => {
        this.error.set(error);
        return of(null);
      })
    )
  );

  …
}

The problem with this approach is that side effects will often cause inconsistencies. As we manually set the error signal, we have to also manually set it to null when back on track, otherwise, here is what can happen:

The error sticks there even after we move to the next recipe.

In order to fix this, we can either add some additional spaghetti code… or wait a bit. Sorry for the suspense!

✅ We’re not done yet!

Remember that Observables can emit multiple values! Suppose that our getRecipe() method still fetches the recipe from a remote service but it might emit a first value from some cache while it fetches a fresher version of the recipe from a remote service.

Even if we receive the first cached value, we might want to still show a progress bar until the stream is complete in order to let the user know that we are still trying to load some additional or fresher data.

The current state is neither pending nor done but somewhere in between.

The problem we have here is that the Signal somehow “swallowed” the “complete” notification and we have no built-in way of knowing if the stream is finished or not.
We have to figure out a better way than combining the finalize() operator with another Signal just like we did with catchError(). Otherwise, we would encounter the same inconsistency problems described above.

@Component({
  …
  template: `
    <mc-progress-bar *ngIf="!finalized()"/>
    <app-recipe *ngIf="recipe() as recipeValue" [recipe]="recipeValue" />
  `,
})
export class AppComponent {
  finalized = signal(false);
  recipe = toSignal(
    this.getRecipe().pipe(
      finalize(() => this.finalized.set(true))
    )
  );

  …
}

🪄 Suspensify

We need to figure out a way of mapping Observables to a richer type of Signal that would contain a consistent and current projection of the Observable's state.

The materialize operator sounds like the natural option, but it doesn’t solve our problem for the following reasons:

it doesn’t emit anything before the first value, error, or “complete” notification, so we have to emit in initial “started” notification,
the “complete” notification doesn’t contain the last emitted value, so we have to somehow remember it (e.g. by applying a reducer using the scan operator).

This “Observable projection problem” is not new or solely related to Signals. This also happens when we try to project the current status of an asynchronous task in NgRx effects or when using RxAngular’s connect method.
That is the reason why we created the suspensify() operator with my friend Edouard Bozon a few years ago. Cf. https://github.com/jscutlery/devkit/tree/main/packages/operators

This operator produces an observable that will always have an initial value and that never throws an error.

Instead of emitting the Observable values, it will emit a Suspense object containing different properties that will tell us about the current state of the Observable.

The example below:

this.getRecipe()
  .pipe(suspensify())
  .subscribe(value => console.log(value));

could emit the following values if the Observables emits a value then fails.

{pending: true, finalized: false, hasError: false, hasValue: false}
{pending: false, finalized: false, hasError: false, hasValue: true, value: '🍔'}
{pending: false, finalized: true, hasError: true, hasValue: false, error: '💥'}

We can turn this into a Signal that will always have an initial value and never throw.

recipe = toSignal(this.getRecipe().pipe(suspensify())); // Signal<Suspense<Recipe> | undefined>

Once we try to use this in the template like this we stumble upon an error

<!-- error TS2532: Object is possibly 'undefined' -->
<mc-progress-bar *ngIf=”!recipe().finalized”/>

In fact, the default initial value of a Signal is undefined but we can fix the typing by letting toSignal() know that our Observable will synchronously emit an initial value as we are using suspensify():

recipe = toSignal(this.getRecipe().pipe(suspensify()), {requireSync: true}); // Signal<Suspense<Recipe>>

💪 Type-narrowing in the template

The default behavior of suspensify() is to return a type union in order to help with type narrowing.

Here is an example:

<div *ngIf="suspense.hasError">
  {{ suspense.error }} // ✅
  {{ suspense.value }} // 💥 template compilation error
</div>

<div *ngIf="suspense.hasValue">
  {{ suspense.error }} // 💥 template compilation error
  {{ suspense.value }} // ✅
</div>

While this will avoid some common mistakes and allow us to propagate the right type to the children, it currently doesn’t play well with Signals because the compiler doesn’t know that recipe() will always return the same value during a Change Detection cycle.

<div *ngIf="recipe().hasError">
  {{ recipe().error }} // 💥 template compilation error
  {{ recipe().value }} // 💥 template compilation error
</div>

<div *ngIf="recipe().hasValue">
  {{ recipe().error }} // 💥 template compilation error
  {{ recipe().value }} // 💥 template compilation error
</div>

This is currently in the Angular roadmap and will be fixed in some future version, at least for signal-based components.

Meanwhile, the workaround is to set suspensify’s strict option to false so that the error and value properties are always available but potentially undefined.

recipe = toSignal(this.getRecipe().pipe(suspensify({strict: false})));

<div *ngIf="recipe().hasError">
  {{ recipe().error }} // ✅
  {{ recipe().value }} // ✅
</div>

<div *ngIf="recipe().hasValue">
  {{ recipe().error }} // ✅
  {{ recipe().value }} // ✅
</div>

Another alternative is to use create a local variable using ngIf + as:

<ng-container *ngIf=”recipe() as suspense”>
  <div *ngIf="suspense.hasError">
    {{ suspense.error }} // ✅
    {{ suspense.value }} // 💥
  </div>

  <div *ngIf="suspense.hasValue">
    {{ suspense.error }} // 💥
    {{ suspense.value }} // ✅
  </div>
</ng-container>

While this workaround provides better type narrowing, it is not very convenient and according to Signals RFC, this will probably not work in signal-based components 😕
… but remember! Signal-based components will probably ship with type narrowing in the template.

Finally, we can quickly wrap this in a reusable function:

@Component({
  …
  template: `
<mc-progress-bar *ngIf=”!recipe().finalized”/>

<div *ngIf="recipe().hasError">
  {{ recipe().error }}
</div>

<div *ngIf="recipe().hasValue">
  {{ recipe().value }}
</div>
`
})
class MyCmp {
  recipe = toSuspenseSignal(this.getRecipe());

  getRecipe(): Observable<Recipe> {
    …
  }
}

function toSuspenseSignal<T>(source$: Observable<T>) {
  return toSignal(source$.pipe(suspensify({ strict: false })), {
    requireSync: true,
  });
}

🧳 Key Takeaways

🤝 Signals are not meant to replace Observables.
💪 A simple operator like suspensify() can keep things declarative, and thus consistent, avoiding imperative spaghetti.
🐙 You can use suspensify() in NgRx effects or with RxState in order to connect different sources.

🔗 Links & Upcoming Workshops

👨🏻‍🏫 Workshops

📦 Suspensify Operator

💻 Source Code on Stackblitz

📰 Subscribe to Newsletter

💬 Discuss this on github

Beyond Angular Signals: Signals & Custom Render Strategies

Younes Jaaidi — Mon, 17 Apr 2023 08:35:25 +0000

TL;DR: Angular Signals might make it easier to track all the expressions in a view (Component or EmbeddedView) and schedule custom render strategies in a very surgical way. Thus, enabling some exciting optimizations.

While libraries and frameworks are getting better and better at tracking changes in a fine-grained way and propagating them to the DOM, we might notice that sometimes, the performance bottleneck resides in DOM updates.

Let's explore how Angular Signals could allow us to overcome these performance bottlenecks with custom rendering strategies.

📜 From Tick to Sig

It has been a while now since the Angular team has been exploring (way more than we can think) alternative reactivity models and looking for something that lies between the extremes of naive Zone.js (i.e. Zone.js without OnPush) and Zoneless Angular combined with special pipes & directives like those provided by RxAngular.

... then Pawel Kozlowski joined the Angular team as a full-time member and together with Alex Rickabaugh they merged into Pawælex.

In the meantime, while Ryan Carniato keeps insisting that he did not invent Signals, he undoubtedly made them popular in the JavaScript ecosystem (Cf. The Evolution of Signals in JavaScript) and eventually ended up influencing Angular.

That is how Pawælex & friends: Andrew, Dylan & Jeremy made the Angular Signals RFC happen.

😬 DOM updates are not that cheap

The fantastic thing about Signals is how frameworks and libraries like Angular, SolidJS, Preact or Qwik "magically" track changes and rerender whatever has to rerender without much boilerplate compared to more manual alternatives.

But wait! If they rerender whatever has to rerender, what happens if the performance bottleneck is the DOM update itself?

Let's try updating 10.000 elements every 100ms...

@Component({
  ...
  template: `
    <div *ngFor="let _ of lines">{{ count() }}</div>
  `,
})
export class CounterComponent implements OnInit {
  count = signal(0);
  lines = Array(10_000);

  ngOnInit() {
    setInterval(() => this.count.update(value => value + 1), 100);
  }
}

Oups! We're spending more than 90% of our time rendering...

...and we can notice the frame rate dropping to somewhere around 20fps.

🦧 Let's calm down a bit

The first solution which we might think of is simply updating the Signals only when we want to rerender, but that would require some boilerplate (i.e. creating intermediate Signals, which are not computed Signals!), and this is how it would look like if we want to throttle a Signal:

@Component({
  ...
  template: `{{ throttledCount() }}`
})
class MyCmp {
  count = signal(0);
  throttledCount = throttleSignal(this.count, {duration: 1000});
  ...
}

Cf. throttleSignal().

but this has a couple of drawbacks:

🐞 using a single unthrottled Signal in the same view would defeat our efforts,
⏱️ if intermediate Signals scheduled updates are not coalesced, we might introduce some random inconsistencies and break the whole glitch-free implementation of Signals.

📺 Updating the viewport only

What if the browser was sensitive? It would turn to us and say: "I'm tired of working so much and nobody cares about my efforts! From now on, I won't work if you don't look at me!"

We might probably agree!

In fact, why would we keep updating below the fold elements? Or more generally, why would we keep updating elements outside the viewport?

If we tried to implement this using an intermediate Signal, then the function would need a reference to the DOM element in order to know if it's in the viewport:

lazyCount = applyViewportStrategy(this.count, {element});

this would require more boilerplate and as the same Signal might be used in different places, then we would need an intermediate Signal for each usage.

While this could be solved using a structural directive, we would clutter the template instead:

template: `
  <span *lazyViewportSignal="count(); let countValue">{{ countValue }}</span>
  <span> x 2 = </span>
  <span *lazyViewportSignal="double(); let doubleValue">{{ doubleValue }}</span>
`

... which is far from ideal.

🤔 What about Eventual Consistency for DOM updates?

Another alternative is acting at the change detection level. If we can customize the rendering strategy, then we can easily postpone the rendering of the content below the fold.

More precisely, we could stop updating the content outside the viewport until it's in the viewport.

While introducing such inconsistency between the state and the view might sound frightening. If applied wisely, this is nothing more than Eventual Consistency, meaning that we will eventually end up in a consistent state.

After all, we could state the following theorem (obviously inspired by the CAP Theorem)

The process of synchronizing the state and the view can't guarantee both consistency and availability.

Inspired by the work of my RxAngular friends, I thought that by combining something like custom render strategies with the Signals tracking system, we could get the best of both worlds and achieve our goal in the most unobtrusive way.

This could look something like this:

@Component({
  ...
  template: `
    <div *viewportStrategy>
      <span>{{ count() }}</span>
      <span> x 2 = </span>
      <span>{{ double() }} </span>
    </div>
  `,
})
export class CounterComponent implements OnInit {
  count = Signal(0);
  double = computed(() => count());
}

👨🏻‍🍳 Sneaking between Signals & Change Detection

Obviously, my first move was to ask the Angular team (more precisely, my dear friend Alex who is now part of Pawælex as mentioned before) if there were any plans to provide an API to override how Signals trigger Change Detection.

Alex said: no.

I heard: not yet.

Then I said: thanks.

And we simultaneously said: bye.

That's when I put on my coding apron and started trying some naive stuff.

My first try was nothing more than something like this:

/**
 * This doesn't work as expected!
 */
const viewRef = vcr.createEmbeddedView(templateRef);
viewRef.detach();
effect(() => {
  console.log('Yeay! we are in!'); // if called more than once
  viewRef.detectChanges();
});

... but it didn't work.

The naive idea behind this was that if effect() can track Signal calls and if detectChanges() has to synchronously call the Signals in the view, then the effect should run again each time a Signal changes.

That's when I realized that we are lucky that this doesn't work because otherwise, this would mean that we would trigger change detection on our view whenever a Signal changes in any child or deeply nested child.

Something at the view level stopped the propagation of the Signals and acted as a boundary mechanism. I had to find what it was, and the best way was to jump into the source code.

(Yeah! I know... I like to try random stuff first 😬)

🔬 The Reactive Graph

In order for the Signals to track changes, Angular has to build a reactive graph. Each node in this graph extends the ReactiveNode abstract class.

There are currently four types of reactive nodes:

Writable Signals: signal()
Computed Signals: computed()
Watchers: effect()
the Reactive Logical View Consumer: the special one we need 😉 (the introduction of Signal-based components will probably add more node types like component inputs)

Each ReactiveNode knows all of its consumers and producers (which are all ReactiveNodes). This is necessary in order to achieve the push/pull glitch-free implementation of Angular Signals.

This reactive graph is built using the setActiveConsumer() function which sets the currently active consumer in a global variable which is read by the producer when called in the same call stack.

Finally, whenever a reactive node might have changed, it notifies its consumers by calling their onConsumerDependencyMayHaveChanged() method.

🎯 The Reactive Logical View Consumer

While spelunking, and ruining my apron, I stumbled upon a surprising reactive node type that lives in IVy' renderer source code, the ReactiveLViewConsumer.

While writable Signals are the leaf nodes of the reactive graph, the Reactive Logical View Consumers are the root nodes.

Just like any other reactive node, this one implements the onConsumerDependencyMayHaveChanged() method, but not like any other reactive node, this one is bound to a view so it can control the change detection... and it does! by marking the view as dirty when notified by a producer:

onConsumerDependencyMayHaveChanged() {
  ...
  markViewDirty(this._lView);
}

🐘 Sneaking (like an elephant) between Signals & Change Detection

Sadly, there doesn't seem to be any elegant way of overriding the current behavior of marking the view to check when Signals trigger a change notification...

...but, luckily, I have my coding apron on, so I am not afraid of getting dirty.

1. Create the embedded view

First, let's create a typical structural directive so we can create & control the embedded view.

@Directive({
  standalone: true,
  selector: '[viewportStrategy]',
})
class ViewportStrategyDirective {
  private _templateRef = inject(TemplateRef);
  private _vcr = inject(ViewContainerRef);

  ngOnInit() {
    const viewRef = this._vcr.createEmbeddedView(this._templateRef);
  }
}

2. Trigger change detection once

For some reason, the ReactiveLViewConsumer is instantiated after the first change detection. My apron was already too dirty to dive any deeper, but my guess is that it is lazily initialized when Signals are used for performance's sake.

The workaround is to trigger change detection once before detaching the change detector:

viewRef.detectChanges();

viewRef.detach();

Aha! While writing this, I stumbled upon this comment here... so I was right! Finally once! Yeah!

3. Grab the `ReactiveLViewConsumer`

🙈

const reactiveViewConsumer = viewRef['_lView'][REACTIVE_TEMPLATE_CONSUMER /* 23 */];

4. Override the Signal notification handler like a monkey

Now that we have the ReactiveLViewConsumer instance, we can let the hacker in us override the onConsumerDependencyMayHaveChanged() method and trigger/skip/schedule change detection with the strategy of our choice, like a naive throttle:

let timeout;
reactiveViewConsumer.onConsumerDependencyMayHaveChanged = () => {
  if (timeout != null) {
    return;
  }

  timeout = setTimeout(() => {
    viewRef.detectChanges();
    timeout = null;
  }, 1000);
};

... or we can use RxJS which is still one of the most convenient ways of handling timing-related strategies (and it is already bundled anyway in most apps 😉)

Cf. ThrottleStrategyDirective & ViewportStrategyDirective

🚀 and it works!

Let's try!

This seems to be at least 5 times faster... (even though, tracking the element's appearance in the viewport is a relatively expensive task)

and the frame rate is pretty decent:

... but note that:

This might break in any future version (major or minor) of Angular. Maybe, you shouldn't do this at work.

Also, this only tracks the view handled by the directive. It won't detach and track child views or components.

🔮 What's next?

🚦 RxAngular + Signals

The strategies implemented in our demo are willingly naive and need better scheduling and coalescing to reduce the amount of reflows & repaints.
Instead of venturing into that, this could be combined with RxAngular Render Strategies... wink, wink, wink! 😉 to my RxAngular friends.

🅰️ We might need more low-level Angular APIs

To achieve our goal, we had to hack our way into Angular internals which might change without notice in future versions.

If Angular could provide some additional APIs like:

interface ViewRef {
  /* This doesn't exist. */
  setCustomSignalChangeHandler(callback: () => void);
}

... or something less verbose 😅, we could combine this with ViewRef.detach() and easily sneak in between Signals and change detection.

Signal-Based Components

As of today, Signal-based components are not implemented yet so there is no way to know if this would work, as implementation details will probably change.

⚛ Custom Render Strategies in some other Libraries & Frameworks

What about other libraries and frameworks?

I couldn't refrain from asking, so I did and received interesting feedback from SolidJS's Ryan Carniato & Preact's Jason Miller:

SolidJS

Preact

React

In React, no matter if we are using Signals or not, we could implement a Higher Order Component that decides whether to really render or return a memoized value depending on its strategy.

const CounterWithViewportStrategy = withViewportStrategy(() => <div>{count}</div>);

export function App() {
  ...
  return <>
    {items.map(() => <CounterWithViewportStrategy count={count}/>}
  </>
}

Cf. React Custom Render Strategies Demo

This could probably be more efficient with Signals if achieved by wrapping React.createElement like Preact Signals integration does and implementing a custom strategy instead of the default behavior.
Or maybe, using a custom hook based on useSyncExternalStore().

Vue.js

Using JSX, we could wrap the render() just like withMemo() does:

defineComponent({
  setup() {
    const count = ref(0);

    return viewportStrategy(({ rootEl }) => (
      <div ref={rootEl}>{ count }</div>
    ));
  },
})

Cf. throttle example on Stackblitz

... but I'm still wondering how this could work in SFC without having to add a compiler node transform to convert something like v-viewport-strategy into a wrapper. 🤔

Qwik

This one needs a bit more investigation 😅, and I am not sure if overriding the default render strategy is currently feasible.
However, my first guess would be that this can be "qwikly" added to the framework.
For example, there could be an API allowing us to toggle a component's "DETACHED" flag which would skip scheduling component render in notifyRender().

👨🏻‍🏫 Closing Observations

☢️ Please, don't do this at work!

The presented solution is based on internal APIs that might change at any moment, including the next Angular minor or patch versions.

So why write about it? My goal here is to show some new capabilities that could be enabled thanks to Signals while improving the Developer eXperience at the same time.

Wanna try custom render strategies before switching to Signals?

Check out RxAngular's template

Conclusion

While custom render strategies can instantly improve performance in some specific situations, the final note is that you should prefer keeping a low number of DOM elements and reducing the number of updates.

In other words, keep your apps simple (as much as you can), organized, and your data flow optimized by design using fine-grained reactivity (whether you are using RxJS-based solutions, or Signals).

🔗 Links & Upcoming Workshops

👨🏻‍🏫 Workshops

📰 Subscribe to Newsletter

💻 Source Code Repository

💬 Discuss this on github

Beyond Angular Signals: Signals & Custom Render Strategies

Younes Jaaidi — Fri, 07 Apr 2023 08:16:55 +0000

While libraries and frameworks are getting better and better at tracking changes in a fine-grained way and propagating them to the DOM, we might notice that sometimes, the performance bottleneck resides in DOM updates.

Let's explore how Angular Signals could allow us to overcome these performance bottlenecks with custom rendering strategies.

📜 From Tick to Sig

... then Pawel Kozlowski joined the Angular team as a full-time member and together with Alex Rickabaugh they merged into Pawælex.

That is how Pawælex & friends: Andrew, Dylan & Jeremy made the Angular Signals RFC happen.

😬 DOM updates are not that cheap

But wait! If they rerender whatever has to rerender, what happens if the performance bottleneck is the DOM update itself?

Let's try updating 10.000 elements every 100ms...

@Component({
  ...
  template: `
    <div *ngFor="let _ of lines">{{ count() }}</div>
  `,
})
export class CounterComponent implements OnInit {
  count = signal(0);
  lines = Array(10_000);

  ngOnInit() {
    setInterval(() => this.count.update(value => value + 1), 100);
  }
}

Oups! We're spending more than 90% of our time rendering...

...and we can notice the frame rate dropping to somewhere around 20fps.

🦧 Let's calm down a bit

@Component({
  ...
  template: `{{ throttledCount() }}`
})
class MyCmp {
  count = signal(0);
  throttledCount = throttleSignal(this.count, {duration: 1000});
  ...
}

Cf. throttleSignal().

but this has a couple of drawbacks:

🐞 using a single unthrottled Signal in the same view would defeat our efforts,
⏱️ if intermediate Signals scheduled updates are not coalesced, we might introduce some random inconsistencies and break the whole glitch-free implementation of Signals.

📺 Updating the viewport only

What if the browser was sensitive? It would turn to us and say: "I'm tired of working so much and nobody cares about my efforts! From now on, I won't work if you don't look at me!"

We might probably agree!

In fact, why would we keep updating below the fold elements? Or more generally, why would we keep updating elements outside the viewport?

If we tried to implement this using an intermediate Signal, then the function would need a reference to the DOM element in order to know if it's in the viewport:

lazyCount = applyViewportStrategy(this.count, {element});

this would require more boilerplate and as the same Signal might be used in different places, then we would need an intermediate Signal for each usage.

While this could be solved using a structural directive, we would clutter the template instead:

template: `
  <span *lazyViewportSignal="count(); let countValue">{{ countValue }}</span>
  <span> x 2 = </span>
  <span *lazyViewportSignal="double(); let doubleValue">{{ doubleValue }}</span>
`

... which is far from ideal.

🤔 What about Eventual Consistency for DOM updates?

Another alternative is acting at the change detection level. If we can customize the rendering strategy, then we can easily postpone the rendering of the content below the fold.

More precisely, we could stop updating the content outside the viewport until it's in the viewport.

After all, we could state the following theorem (obviously inspired by the CAP Theorem)

The process of synchronizing the state and the view can't guarantee both consistency and availability.

This could look something like this:

@Component({
  ...
  template: `
    <div *viewportStrategy>
      <span>{{ count() }}</span>
      <span> x 2 = </span>
      <span>{{ double() }} </span>
    </div>
  `,
})
export class CounterComponent implements OnInit {
  count = Signal(0);
  double = computed(() => count());
}

👨🏻‍🍳 Sneaking between Signals & Change Detection

Alex said: no.

I heard: not yet.

Then I said: thanks.

And we simultaneously said: bye.

That's when I put my coding apron and started trying some naive stuff.

My first try was nothing more than something like this:

/**
 * This doesn't work as expected!
 */
const viewRef = vcr.createEmbeddedView(templateRef);
viewRef.detach();
effect(() => {
  console.log('Yeay! we are in!'); // if called more than once
  viewRef.detectChanges();
});

... but it didn't work.

The naive idea behind this was that if effect() can track Signal calls and if detectChanges() has to synchronously call the Signals in the view, then the effect should run again each time a Signal changes.

Something at the view level stopped the propagation of the Signals and acted as a boundary mechanism. I had to find what it was, and the best way was to jump into the source code.

(Yeah! I know... I like to try random stuff first 😬)

🔬 The Reactive Graph

In order for the Signals to track changes, Angular has to build a reactive graph. Each node in this graph extends the ReactiveNode abstract class.

There are currently four types of reactive nodes:

Writable Signals: signal()
Computed Signals: computed()
Watchers: effect()
the Reactive Logical View Consumer: the special one we need 😉 (the introduction of Signal-based components will probably add more node types like component inputs)

Each ReactiveNode knows all of its consumers and producers (which are all ReactiveNodes). This is necessary in order to achieve the push/pull glitch-free implementation of Angular Signals.

This reactive graph is built using the setActiveConsumer() function which sets the currently active consumer in a global variable which is read by the producer when called in the same call stack.

Finally, whenever a reactive node might have changed, it notifies its consumers by calling their onConsumerDependencyMayHaveChanged() method.

🎯 The Reactive Logical View Consumer

While spelunking, and ruining my apron, I stumbled upon a surprising reactive node type that lives in IVy' renderer source code, the ReactiveLViewConsumer.

While writable Signals are the leaf nodes of the reactive graph, the Reactive Logical View Consumers are the root nodes.

onConsumerDependencyMayHaveChanged() {
  ...
  markViewDirty(this._lView);
}

🐘 Sneaking (like an elephant) between Signals & Change Detection

Sadly, there doesn't seem to be any elegant way of overriding the current behavior of marking the view to check when Signals trigger a change notification...

...but, luckily, I have my coding apron on, so I am not afraid of getting dirty.

1. Create the embedded view

First, let's create a typical structural directive so we can create & control the embedded view.

@Directive({
  standalone: true,
  selector: '[viewportStrategy]',
})
class ViewportStrategyDirective {
  private _templateRef = inject(TemplateRef);
  private _vcr = inject(ViewContainerRef);

  ngOnInit() {
    const viewRef = this._vcr.createEmbeddedView(this._templateRef);
  }
}

2. Trigger change detection once

The workaround is to trigger change detection once before detaching the change detector:

viewRef.detectChanges();

viewRef.detach();

Aha! While writing this, I stumbled upon this comment here... so I was right! Finally once! Yeah!

3. Grab the `ReactiveLViewConsumer`

🙈

const reactiveViewConsumer = viewRef['_lView'][REACTIVE_TEMPLATE_CONSUMER /* 23 */];

4. Override the Signal notification handler like a monkey

let timeout;
reactiveViewConsumer.onConsumerDependencyMayHaveChanged = () => {
  if (timeout != null) {
    return;
  }

  timeout = setTimeout(() => {
    viewRef.detectChanges();
    timeout = null;
  }, 1000);
};

... or we can use RxJS which is still one of the most convenient ways of handling timing-related strategies (and it is already bundled anyway in most apps 😉)

Cf. ThrottleStrategyDirective & ViewportStrategyDirective

🚀 and it works!

Let's try!

This seems to be at least 5 times faster... (even though, tracking the element appearance in the viewport is a relatively expensive task)

and the frame rate is pretty decent:

... but note that:

This might break in any future version (major or minor) of Angular. Maybe, you shouldn't do this at work.

Also, this only tracks the view handled by the directive. It won't detach and track child views or components.

🔮 What's next?

🚦 RxAngular + Signals

The strategies implemented in our demo are willingly naive and they need better scheduling and coalescing to reduce the amount of reflows & repaints.
Instead of venturing into that, this could be combined with RxAngular Render Strategies... wink, wink, wink! 😉 to my RxAngular friends.

🅰️ We might need more low-level Angular APIs

To achieve our goal, we had to hack our way into Angular internals which might change without notice in future versions.

If Angular could provide some additional APIs like:

interface ViewRef {
  /* This doesn't exist. */
  setCustomSignalChangeHandler(callback: () => void);
}

... or something less verbose 😅, we could combine this with ViewRef.detach() and easily sneak in between Signals and change detection.

Signal-Based Components

As of today, Signal-based components are not implemented yet so there is no way to know if this would work, as implementation details will probably change.

⚛ Custom Render Strategies in some other Libraries & Frameworks

What about other libraries and frameworks?

I couldn't refrain from asking, so I did and received interesting feedback from SolidJS's Ryan Carniato & Preact's Jason Miller:

SolidJS

Preact

React

In React, no matter if we are using Signals or not, we could implement a Higher Order Component that decides whether to really render or return a memoized value depending on its strategy.

const CounterWithViewportStrategy = withViewportStrategy(() => <div>{count}</div>);

export function App() {
  ...
  return <>
    {items.map(() => <CounterWithViewportStrategy count={count}/>}
  </>
}

Cf. React Custom Render Strategies Demo

Vue.js

Using JSX, we could wrap the render() just like withMemo() does:

defineComponent({
  setup() {
    const count = ref(0);

    return viewportStrategy(({ rootEl }) => (
      <div ref={rootEl}>{ count }</div>
    ));
  },
})

Cf. throttle example on Stackblitz

... but I'm still wondering how this could work in SFC without having to add a compiler node transform to convert something like v-viewport-strategy into a wrapper. 🤔

Qwik

👨🏻‍🏫 Closing Observations

☢️ Please, don't do this at work!

The presented solution is based on internal APIs that might change at any moment, including the next Angular minor or patch versions.

So why write about it? My goal here is to show some new capabilities that could be enabled thanks to Signals while improving the Developer eXperience at the same time.

Wanna try custom render strategies before switching to Signals?

Check out RxAngular's template

Conclusion

In other words, keep your apps simple (as much as you can), organized, and your data flow optimized by design using fine-grained reactivity (whether you are using RxJS-based solutions, or Signals).

🔗 Links & Upcoming Workshops

👨🏻‍🏫 Workshops

📰 Subscribe to Newsletter

💻 Source Code Repository

💬 Discuss this on github

Wiprecation

Younes Jaaidi — Wed, 09 Dec 2020 22:43:49 +0000

🚧 Work in progress

Wiprecation: documenting that new code is not ready yet when Branching by Abstraction, or using TCR or Timeboxed TDD.

Spice Up your Caching with Convoyr

Younes Jaaidi — Tue, 17 Nov 2020 12:55:33 +0000

Where it All Started

Most web apps get their value from interacting with HTTP APIs.
This is generally done using HTTP clients like the native fetch function, Axios or Angular's HttpClient.

Once you set up an HTTP client on a web app then sooner or later, you will need to extend its capabilities in order to handle different topics like User Experience (e.g. pending requests indicator), performance (e.g. caching), resilience (e.g. automatic retry), and security (e.g. authentication). Luckily, most HTTP clients can be easily extended using interceptors so you won't have to wrap them or implement your own client.

Even though implementing an interceptor can sound quick and easy, handling edge cases, testing and maintenance can get expensive. Wouldn't it be better if someone else could handle these issues for us?

That's when my friend Edouard Bozon and I noticed the following facts:

most apps including ours, those of our clients (i.e. companies not HTTP ones) and probably yours need the same interceptors,
implementing interceptors can be tricky with some HTTP clients if you are not familiar with some other concepts,
implementations observed in tutorials or in our clients' codebases can be error-prone or miss a couple of important edge cases,
implementing the same interceptor more than once in a lifetime is a boring waste of time.

The next thing I remember is that we decided to react by initiating an open-source library called Convoyr.

💡 The Idea Behind Convoyr

While Convoyr is currently focused on extending Angular's HttpClient it has been designed as a modular and framework agnostic set of plugins.

We like to think of Convoyr as an infrastructure agnostic Service Mesh for web apps and JavaScript... even if we are not there yet.

🐢 The Network Latency Performance Problem

Today, in this blog post, we will focus on the performance topic and how to fix network latency issues using Convoyr.

In most cases, when a user navigates from a route to another on the same web app, the main thing preventing us from displaying the result instantly is the network latency related to fetching data from some remote service.

This can be problematic, especially when it comes to re-fetching some data that we have just fetched a few minutes ago and that didn't change since. We end up making the user wait to finally display the same result as he received before.
Imagine a list of products where the user clicks on a specific product to see its details before clicking the "back to the list" button. The latency due to re-fetching the products can cause friction.

🚒 Caching to the Rescue

One of the first solutions we can think of is caching. We can implement our own caching system or just set the right response headers and let the browser handle the HTTP caching as described by RFC7234.
The latter approach is generally the most appropriate as it is standard, generic, efficient, scalable, sharable, easy to set up, and cheap to maintain.

🍺 The Freshness Problem

HTTP caching is relatively easy to set up but it comes with a price, the price of freshness.
In fact, in order to cache a response, the server has to tell the client how long it can cache it or in other terms, how long it should be considered fresh.

Choosing a freshness duration can be a challenging decision.

Too low and it would render the cache useless; too high and the web app would use the "expired" data returned by the cache.

🤔 Why make a choice

Software development is all about tradeoffs but what if we could skip this one.

Wouldn't it be nice if we could use the latest data from the cache while we are fetching the freshest one from the network?

We can imagine many ways of implementing this behavior but let's focus on Developer eXperience and find an approach that works globally without having to change all the HTTP calls in our apps.

Observable vs Promise

Angular's HTTPClient has the specificity of returning observables instead of promises in opposition to the native fetch function and Axios.

Amongst other advantages like making HTTP calls lazy and easily cancelable, observables offer an additional benefit which is the ability to emit multiple values.

✌️ Emit both cached & network

As we can emit multiple values with observables, what about first emitting the data from the cache (if available) and then the data from the network?

This means that given the code below in our Angular component, we wouldn't have to change anything and it would first display the cached result and refresh it with the latest result from the network.

@Component({
  template: `{{ weather | json }}`
})
export class WeatherComponent {
  weather: Weather;

  ...() {
    this.http.get<Weather>('/weather/lyon')
      .subscribe(weather => this.weather = weather);
  }

}

or in a more reactive way:

@Component({
  template: `{{ weather$ | async | json }}`
})
export class WeatherComponent {
  weather$ = this.http.get<Weather>('/weather/lyon');
}

Convoyr cache plugin

Convoyr provides a cache plugin @convoyr/plugin-cache that extending the behavior of the HTTP client by first emitting the data from the cache if available then the one from the network as described above.

Setup

It takes two steps to setup Convoyr's cache plugin.

Installing Convoyr and the plugin:

npm install @convoyr/core @convoyr/angular @convoyr/plugin-cache

Enable the cache plugin in the AppModule:

import { ConvoyrModule } from '@convoyr/angular';
import { createCachePlugin } from '@convoyr/plugin-cache';

@NgModule({
  imports: [
    ...
    HttpClientModule,
    ConvoyrModule.forRoot({
      plugins: [createCachePlugin()],
    }),
  ],
  ...
})
export class AppModule {}

How to know if the data comes from cache

You will probably want to display the data differently when it comes from the cache or when it's all fresh from the network.

Convoyr's cache plugin can provide some metadata on the emitted response by setting the addCacheMetadata to true.

createCachePlugin({
  addCacheMetadata: true
})

Be careful though as this will change the response type.

The code below:

http.get('/weather/lyon')
  .subscribe(data => console.log(data));

... will log the following data:

{
  data: {
    temperature: ...,
    ...
  },
  cacheMetadata: {
    createdAt: '2020-01-01T00:00:00.000Z',
    isFromCache: true
  }
}

Convoyr's cache plugin is progressive

The addCacheMetadata can be very interesting but it is also kind of intrusive as it changes the response type.
Enabling it globally on some apps can require a terrific refactoring.

In order to avoid the trouble and let you enable this option progressively, the cache plugin allows you to activate different configurations on different groups of requests using the shouldHandleRequest option.

import { and, matchOrigin, matchPath } from '@convoyr/core';

createCachePlugin({
  shouldHandleRequest: and(
    matchOrigin('marmicode.io'),
    matchPath('/weather')
  )
})

Storage

By default, the cache plugin stores the 100 most recently used requests in memory.

You can override this behavior by providing your own storage or instantiating the MemoryStorage with the size of your choice using the maxSize option.

createCachePlugin({
  storage: new MemoryStorage({ maxSize: 2000 }), // 2000 requests
})

createCachePlugin({
  storage: new MemoryStorage({ maxSize: '2 mb' }), // 2MB
})

🚀 Upcoming Features

This is just the beginning and there is more to come so stay tuned.

Here is a list of some upcoming features:

Handle ReSTful APIs (e.g. /items should populate /items/:itemId so we can instantly show partial data from list views in detail views)
Use IndexedDB as storage.

🔌 Other plugins

@convoyr/plugin-auth handles authentication both easily and securely.
@convoyr/plugin-retry handles backoff (i.e. retries when things go wrong).

📝 Other Articles about Convoyr

End-to-End HTTP request cancelation with RxJS & NestJS

Younes Jaaidi — Fri, 21 Feb 2020 09:01:33 +0000

Life is too short. When searching for something, we can’t afford to type a whole word or sentence in a search field, or filling all the fields then hitting our old keyboard’s half-broken enter key to finally be able to see the first results... or nothing at all because our search criteria were too restrictive.

Don’t look at me like that! We can probably agree that most of us, if not all, are used to features like typeahead and live search results. We get frustrated every time we have to submit a search form.

TL;DR:

if you are using NestJS, you will need this interceptor,
if you are not using NestJS then maybe you should,
we have to think reactively, I agree that it can have a steep learning curve but think about the pleasure of sliding on the other side of the hill ⛷,
we can and should use RxJS everywhere,
we should use observables even for single value streams,
we should not ignore observables teardown logic.

🚨 Reactive Programming & RxJS to the rescue

Implementing these kinds of features can be tricky, especially if developed from scratch and with an imperative approach. That’s when reactive programming and RxJS come to the rescue. In fact, RxJS provides the right tooling and operators to implement these features in a few lines.
RxJS is such a perfect fit for these scenarios that most courses and tutorials cover the live search topic. It helps understand both how reactive programming works and how it can easily solve some challenging issues.

That’s when we end up with this common recipe:

keywords$ = this.keywordsControl.valueChanges;
data$ = keywords$.pipe(
  /* Wait for the user to stop typing for 100ms and emit last value. */
  debounceTime(100),
  /* Ignore identical successive values
   * (e.g. user pastes the same value in the input). */
  distinctUntilChanged(), 
  /* when new keywords are emitted, this unsubscribes from the previous
   * search result (canceling the underlying http request)
   * and subscribes to the new one. */
  switchMap(keywords => this.search(keywords))
)

The illustration below might help you notice the difference between RxJS flattening strategies and the related operators:

but if it doesn't help, you should definitely check out the great work by my buddy Shai Reznik: https://medium.com/@shairez/a-super-ninja-trick-to-learn-rxjss-switchmap-mergemap-concatmap-and-exhaustmap-forever-88e178a75f1b

🐢 Hey Debounce! Stop bullying my low latency!

The problem is that you are probably investing a lot of energy and money in producing low latency architectures and APIs but all these efforts just vanish when we introduce the artificial latency created by the debounceTime operator.

What if we just get rid of the debounce? We are using switchMap after all, and unnecessary requests are immediately canceled.

Wait a second! What happens on the back-end? Is the back-end "work" interrupted by some voodoo magic? Or did we just trigger some crazy chaos where the back-end is working for nothing until it realizes that the consumer is not there anymore?

🐈 Here comes the big cat

In a few words, NestJS is THE feature-rich NodeJS framework.

Amongst its wealth of features, there is native support of observables. This is quite handy even if we respond with a single value and not a stream of values. In fact, the interesting observables property we are looking for here is cancelability.

🧨 Observables Teardown Logic

Observables are said cancelable because we can unsubscribe whenever we need to, and interrupt the work. Cancelation works thanks to the teardown logic function returned when creating an observable.

Here’s an example of wrapping setInterval in an observable:

function interval(period) {
  return new Observable(observer => {
    let i = 0;
    const handle = setInterval(() => observer.next(i++), period);
    /* This is the teardown logic. */
    return () => clearInterval(handle);
  });
}

As you can see, the observer function given to the Observable's constructor returns the teardown logic function that calls clearInterval in order to cancel the tasks scheduled by setInterval.

⚠️ This is exactly how you should NOT implement an interval.
This implementation is scheduler naive.
You should use interval or timer instead.

🧪 The experiment

For the experiment, I needed to run some slow CPU, filesystem and memory intensive work on the back-end for every request. The first idea that crossed my mind was reading a big text file line by line and matching every one of them against the given keywords.
It turned out that even with a 1GB file, it was still quite fast.

That’s when I thought that reading multiple small files should be more inefficient. I just needed to generate a directory with lots of files... but wait! What about using node_modules directory 🤔

Bingo! It could not be worse and that is exactly what I needed.

The implementation looks something like this and as you can see, the teardown logic immediately stops crawling the directory and reading files when the observer unsubscribes.

function getFiles(directoryPath) {
  return new Observable(observer => {
    ...
    return () => walker.pause();
  }
}

function readLines(filePath) {
  return new Observable(observer => {
    ...
    return () => reader.close();
  }
}

function search(): Observable<Line[]> {
  return getFiles(nodeModulesPath)
    .pipe(
      mergeMap(file => readLines(file)),
      ...
    );
}

😔 The disappointment

In the animation below, we can observe high CPU usage and an exponential memory usage on the back-end and that canceling the requests, even the last one, doesn’t interrupt the work.

By diving a little bit in Nest’s source code, we can see that our observable is converted to a promise using toPromise method. In fact, Nest has to adapt to frameworks like ExpressJS that don’t handle observables.

  public async transformToResult(resultOrDeferred: any) {
    if (resultOrDeferred && isFunction(resultOrDeferred.subscribe)) {
      return resultOrDeferred.toPromise();
    }
    return resultOrDeferred;
  }

🔍 Detecting request cancelation

In Nest, request objects are instances of NodeJS’ IncomingMessage that trigger a close event when the connection is closed or when the HTTP2 stream is closed.

If we can detect when the request is canceled, then we can interrupt the work in our RxJS response stream.

aborted vs close: IncomingMessage also triggers an aborted event that you can ignore as it will probably be deprecated in the future. Cf. https://github.com/nodejs/node/issues/15456 & https://github.com/nodejs/node/issues/15525.

Nest has an interesting concept called interceptors:

Interceptors have a set of useful capabilities which are inspired by the Aspect Oriented Programming (AOP) technique.

and it looks like this:

@Injectable()
export class NoopInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<unknown> {
    return next.handle();
  }
}

This makes it possible to write, in a single place, a function that:

intercepts every incoming HTTP request,
listens to the request’s close event,
does something to interrupt the work.

One of the interesting properties of Nest interceptors, compared to Express middlewares for example, is that the next parameter is not just a function that triggers the route function or the next middleware but it is an object with a handle method that returns an Observable.

Thanks to this feature, we can manipulate the response and the whole stream by adding operators to the given Observable.

For instance, we can detect the request cancelation by listening to the close event using RxJS's fromEvent and interrupt the Observable returned by the route handler using the takeUntil operator.

The final interceptor should look like this:

@Injectable()
export class UnsubscribeOnCloseInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<unknown> {
    if (context.getType() !== 'http') {
      return next.handle();
    }

    const request = context.switchToHttp().getRequest() as Request;

    const close$ = fromEvent(request, 'close');

    return next.handle().pipe(takeUntil(close$));
  }
}

Let's try it out!

As you can observe, thanks to the interceptor, canceling an HTTP request will automatically and almost immediately cancel the work by unsubscribing from the observable returned by the route handler.
This reduces CPU, memory and all resources usage and interrupts all the work even when the user simply closes the window.

🧠 Think reactive

The key takeaway here is that by adopting a reactive approach and using observables everywhere, we can easily benefit from observables cancelability and boost APIs performance with a generic interceptor.

MongoDB query cancelation

What if our data source was a database like MongoDB? Can we interrupt the query?
📻 Stay tuned for an upcoming post on this topic 😉

👨🏻‍🍳 Let me help you!

At Marmicode, we use our passion and experience in Web Development & eXtreme Programming to help you cook better apps, ship them fast and make you proud of your work.

We have the services you need:

Code Review,
Remote Consultations,
Workshops,
On-demand development billed by accepted points.

📨 kitchen at marmicode.io

🔗 Links

💻 Source code Nx monorepo with an Angular app, a NestJS API and custom CPU / Memory graphing app using Angular & GraphQL subscriptions.
🐦 @yjaaidi Stay tuned for more posts and upcoming workshops.

Forem: Younes Jaaidi

Vitest's 4.1 New "Fast-Forward" Mode Skips Timer Delays Instantly

The Challenge with Manual Fake Timers

Solution #1 — Real Time and Polling

Solution #2 — Dynamic Timing Configuration

Solution #3 — "Fast-Forward" Mode

Special thanks to Andrew and Vladimir

Going Deeper

The Missing Ingredient for Angular Template Code Coverage and Future-Proof Testing

😧 What's wrong with JIT?

⏰ Why now?

🎁 Other Benefits of AOT Testing

⚡️ Faster Test Execution

👯 Production-Symmetry

🔮 Future-Proof Tests

🤔 Drawbacks

🪄 Dynamic Component Constructs Should Be Avoided

🦦 Shallow Testing is More Challenging

👨🏻‍🍳 Taking Vitest with AOT for a Spin

1. Set up Vitest

2. Enable AOT

📈 Configure Code Coverage

1. Install @vitest/coverage-istanbul

2. Choose istanbul as your coverage provider

🎬 Watch it in Action

☢️ Mind the Code Coverage Trap

🚀 What's Next?

📚 Additional Resources

👨🏻‍🏫 Pragmatic Angular Testing Video Course is Here!

Managing RxJS Traffic with Signals and Suspensify

Will Signals replace RxJS?

✨ Let Signals shine!

♻️ Spinner vertigo

That’s when we might hit a common typing issue:

💥 “Oups! Your valid data is invalid.”

✅ We’re not done yet!

🪄 Suspensify

💪 Type-narrowing in the template

Finally, we can quickly wrap this in a reusable function:

🧳 Key Takeaways

🔗 Links & Upcoming Workshops

Beyond Angular Signals: Signals & Custom Render Strategies

📜 From Tick to Sig

😬 DOM updates are not that cheap

🦧 Let's calm down a bit

📺 Updating the viewport only

🤔 What about Eventual Consistency for DOM updates?

👨🏻‍🍳 Sneaking between Signals & Change Detection

🔬 The Reactive Graph

🎯 The Reactive Logical View Consumer

🐘 Sneaking (like an elephant) between Signals & Change Detection

1. Create the embedded view

2. Trigger change detection once

3. Grab the ReactiveLViewConsumer

4. Override the Signal notification handler like a monkey

🚀 and it works!

🔮 What's next?

🚦 RxAngular + Signals

🅰️ We might need more low-level Angular APIs

Signal-Based Components

⚛ Custom Render Strategies in some other Libraries & Frameworks

SolidJS

Preact

React

Vue.js

Qwik

👨🏻‍🏫 Closing Observations

☢️ Please, don't do this at work!

Wanna try custom render strategies before switching to Signals?

Conclusion

🔗 Links & Upcoming Workshops

Beyond Angular Signals: Signals & Custom Render Strategies

📜 From Tick to Sig

😬 DOM updates are not that cheap

🦧 Let's calm down a bit

📺 Updating the viewport only

🤔 What about Eventual Consistency for DOM updates?

👨🏻‍🍳 Sneaking between Signals & Change Detection

🔬 The Reactive Graph

🎯 The Reactive Logical View Consumer

1. Install `@vitest/coverage-istanbul`

2. Choose `istanbul` as your coverage provider

3. Grab the `ReactiveLViewConsumer`

3. Grab the `ReactiveLViewConsumer`