npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

ngx-rerender

v1.4.0

Published

![GitHub package.json version](https://img.shields.io/github/package-json/v/ngehlert/ngx-rerender) [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT) ![npm](https://img.shields.io/npm/dw/ngx-rerende

Downloads

3,785

Readme

ngx-rerender

GitHub package.json version License: MIT npm Test & Lint Coverage

ngx-rerender is a small Angular library, that allows you to completely re-render a specific component/code block of your application.
In contrast to the regular Angular lifecycle change updates, this will completely render the given code block from scratch, so even hooks like OnInit will be called again.

Table of contents

Installation

See npm documentation on how to get started with npm.

npm install --save ngx-rerender

Usage

Add the module import to your Angular module

import { NgxRerenderModule } from 'ngx-rerender';
@NgModule({
  ...
  imports: [
    ...
    NgxRerenderModule,
  ],
})
export class MyModule {}

With directive

Stackblitz Example
After you've added the module import you can attach the *mcRerender directive to any element you like to rerender.
The directive accepts a parameter that you need to change if you want to trigger the rerender.
In my example I'm going to use a number with increment, but you can also use any data you want that triggers a regular Angular change detection.

class MyComponent {
  public trigger: number = 0;

  public rerender(): void {
    this.trigger++;
  }
}
<stuff-to-rerender *mcRerender="trigger">Some Content</stuff-to-rerender>

Every time the rerender method is called the component that has the directive attached to it will be rerendered.

Keep in mind changing entries inside an array will not trigger an Angular change detection. If you use an array as trigger binding, you need to copy the array in order to get a new reference.

With component

Stackblitz Example
If you prefer using a component in your template you can do the following approach. The TypeScript part can stay exactly the same.
However, if you like you can use a boolean flag and a two-way binding and the component will always change the value back to false. This way you don't need to have a number as trigger, but you can use a boolean value

class MyComponent {
  public trigger: boolean = false;

  public rerender(): void {
    this.trigger = true;
  }
}
<mc-rerender [(trigger)]="trigger">
  <ng-template mcRerenderContent>
    <stuff-to-rerender *mcRerender="trigger">Some Content</stuff-to-rerender>
  </ng-template>
</mc-rerender>

The important part in the component way is the additional <ng-template mcRerenderContent> wrapper around your content.
Do not change this, otherwise it will not work properly.

Why

Angular has a very robust change detection and is usually fully capable of dynamically updating components and bindings without the need to re-render entire code blocks. If you are not familiar with the basics of change detection or are just starting learning Angular, I highly recommend checking out their Documentation, because chances are that you don't even need this library.

Sometimes, especially when using 3rd-party-libraries and components, the Angular change detection is not enough. For example if no ngOnChanges handling is implemented so specific bindings can only be set during ngOnInit.
For those cases you can use this library to just re-render (and re-initialize) entire component trees.

Past workarounds

In this small section I will show some workarounds that I've seen in the past on StackOverflow or other projects and try to explain why they are not a good idea.

The ngIf "Have you tried turning it off and on again?"

The idea is to completely remove the specific component from the DOM, manually trigger a change detection and then re-add it. A basic solution looks something like this

import { ChangeDetectorRef } from '@angular/core';

class MyComponent {
  public isVisible: boolean = true;

  constructor(private changeDetectorRef: ChangeDetectorRef) {}
  
  public rerender(): void {
    this.isVisible = false;
    this.changeDetectorRef.detectChanges();
    this.isVisible = true;
  }
}
<stuff-to-rerender *ngIf="isVisible">Some Content</stuff-to-rerender>

This is a very "straight forward" and often suggested solution. However, it's not ideal for two reasons. First you will notice a "blink" in your page, because there is one entire lifecycle where your component is not visible.
And secondly you trigger a change detection for the entire application. Every other binding and lifecycle hook gets also triggered. This can become an issue in big applications where the ChangeDetectionStrategy.OnPush is not being used.

The ngFor "smart" workaround

The idea is to "trick" Angular into thinking my current element is actually a new one. For this we make use of ngFor which will initialize each entry from scratch once and then only update bindings based on the reference in the array.
If we update the reference in the array it will effectively re-rerender the given code part.

class MyComponent {
  public rerenderProps: Array<number> = [1];
  
  public rerender(): void {
      this.rerenderProps[0]++;
  }
}
<div *ngFor="let i of rerenderProps">
    <stuff-to-rerender>Some Content</stuff-to-rerender>
</div>

While this solves the two issues of the ngIf workaround (content blink and app-wide change detection) this is still not a nice solution.
It is very hard to understand for others looking at your code, and also you always need to implement additional logic like index checks ngIf="index === 0" in order to prevent accidentally showing the component multiple times.

How

I explained the basics in a Blog Post

FAQ

I'm using one of the workarounds (or some other workaround), does it make sense to start using this library?

Yes! While the workarounds all work to some extent they never feel nice to use and always cause confusion for other devs verifying your code.

I found a bug/scenario where it is not working, what shall I do?

Please create an issue with a Stackblitz reproduction and I'm sure we will find a solution

I don't need this why should I use it?

If you don't need it I'm really happy for your. Like I said nearly all my problems where I reach for this library myself are when dealing with 3rd party libraries.

Why are there two different ways of achieving the same thing with this library?

The two ways are not entirely the same. The component approach allows you to use a boolean flag that automatically gets changed back to false - this feels very nice to use. But in contrast the directive way has a smaller code footprint in your html template.
Ultimately it allows you to choose a way that fits your personal style and needs the best.

I'm using a boolean value and the directive way but the content is not being rerendered?

If you are using the directive way you have to use a value that will be picked up by the Angular change detection. If you use a boolean value and change this to true it just will stay true. For this to work you need to set it back to false by yourself (It is sadly not possible for directives to update their binding value)

License

This project is licensed under the MIT license. See the LICENSE file for more info.