github sweetalert2/ngx-sweetalert2 v6.0.0

latest releases: v12.1.0, v12.0.2, v12.0.1...
4 years ago

6.0.0 (2019-09-02)

😅 This version contains broken Angular AoT metadata (it works perfectly in non-AoT builds). Version 6.0.1 fixes it. Like, we can never release a major without immediately breaking that beautiful good round version number 5 minutes later. Y'know, I think that's what happened to Windows 9, they would have had to release version 9.0.1 for some obscure last-minute bug, but management was unhappy so they decided to release version 10 immediately.

For this version 6 release, ngx-sweetalert2 was almost rewritten from scratch, but you'll find the same features you were used to, except they're even better now.

There are a few breaking changes though, but mostly syntactical. The feature set stays the same.
Those release notes will guide you through the migration process.

Make sure that sweetalert2@^8.17.1 at least is installed alongside this release.

But first:

What's new

🎱 SweetAlert2 version 8

...is now properly supported and legacy code was removed.

Version 5.1.0 was able to run it, but didn't make any use of its new features.

🔁 Asynchronous, on-demand loading of the SweetAlert2 library

The previous versions of ngx-sweetalert2 didn't let you choose how SweetAlert2 was imported alongside this integration (unless you knew how to tune your webpack configuration).

And most importantly, SweetAlert2 was loaded with the module, no matter if the user actually went on a page containing a sweet alert or not, and making your main bundles bigger.

Now, you can substitute the runtime version of SweetAlert2 you prefer (ex. styled, unstyled, src or dist, etc), and the default sweetalert2 provider will lazily load SweetAlert2 only when needed!

When a <swal> component (or the directive) is used on the page, ngx-sweetalert2 will transparently start to load SweetAlert2 in the backround, so it's ready to lauch instantly when you finally want to show the alert to the user.

No delay in the first load, no delay on usage! ;)

⚠️ your build system needs to support the asynchronous import() syntax for ngx-sweetalert2 to work now. If you use Angular CLI or a modern Weboack version, you won't have any problem.

🎨 Support for @sweetalert2/themes

The way SweetAlert2 is now imported (see previous point) allows you to use one of the superb alternative SweetAlert2 themes (or use your own).

Will you try our dark, minimal, borderless or bootstrap-4 themes ?

(More documentation will come soon on this)
(Hey, here's some issue I answered with a code example on how to do that)

🔧 Introduced SweetAlert2LoaderService

This injectable service can be required by your components to retrieve the current (module-level) SweetAlert2 instance.

Since the library can now be loaded asynchrously, this service simplifies the complexity this brings and prevents you to import a different build of SweetAlert2 than the one you specified in your module, or worse, importing SweetAlert2 in a synchronous manner, breaking the default asynchronous laoding.

🎯 New *swalPortal targets

By the way, SwalPartialDirective has been renamed to SwalPortalDirective, inspired by the terminology of React and Angular CDK portals.

There are now new portal targets, and the content target (the default one) now targets the text block area, meaning it won't override the input, validation zone, or the other zones a swal can have depending on its options.

That means that you can now use an Angular template into the sweet alert content without losing half of SweetAlert2's features.

📝 Support for live updates of the content of an alert

Previous versions of SweetAlert2 or Ngx-SweetAlert2 were not able to update the contents of a modal that was currently opened.

That first changed with SweetAlert2 version 8, that got a rewrite of its renderer, and a new function, Swal.update(options).

This is now fully supported by ngx-sweetalert2. If you change @Inputs of a <swal> component while it's opened, the modal will be updated, meaning that you can now have some dynamic content without using a portal (previously known as "partial").

Also, thanks to a complete rewrite of the SwalPortalDirective, you can now update an opened <swal> through its component inputs and use portals at the same time, the library will detect the re-rendering of the modal and re-attach the portals on the fly!

Migration Guide

You will find the same features as before, so the migration should be easy, but there are a few syntactical changes.

⚠️ This guide covers 95% of use cases, but it is not exhaustive, we heavily recommend you to check that your swals work as expected after the migration, especially if you used *swalPartial.

Importing SweetAlert2Module

If you used default options, the syntax changed completely, we don't support this natively anymore, you will instead provide you own SweetAlert2 implementation, using SweetAlert2 mixins:

import { SweetAlert2Module } from '@sweetalert2/ngx-sweetalert2';

+// using a separate function for AoT, that doesn't likes arrow syntax expressions in @NgModule
+export function provideSwal() {
+    return import('sweetalert2').then(({ default: Swal }) => Swal.mixin({
+        confirmButtonText: `D'accord`,
+        cancelButtonText: `Annuler`
+    }))
+} 

@NgModule({
    imports: [
        //=> Basic usage (no changes):
        SweetAlert2Module.forRoot(),

        //=> XOR provide default SweetAlert2-native options
        SweetAlert2Module.forRoot({
-            confirmButtonText: `D'accord`,
-            cancelButtonText: `Annuler`,
+            provideSwal
        })
    ]
})
export class AppModule {
}

Importing SweetAlert2Module in a feature module (aka submodule)

import { SweetAlert2Module } from '@sweetalert2/ngx-sweetalert2';

@NgModule({
    imports: [
        //=> In submodules only (no changes):
        SweetAlert2Module,

+        //=> XOR you can now also use this syntax:
+        SweetAlert2Module.forChild(),
    
+        //=> XOR override options from the AppModule:
+        SweetAlert2Module.forChild({
+            // You do not need to specify each key, forChild does not override
+            // the whole object of the parent module, but individual keys.
+            // Keys that are not specified here will simply inherit their values
+            // from the parent module.
+            dismissOnDestroy: false
+        })
    ]
})
export class FeatureModule {
}

Using <swal [options]="{ ... }"></swal> input

In SwalComponent, options has been renamed swalOptions to differentiate it from the other @Inputs that have 1:1 mapping with SweetAlert2 native options.

-<swal [options]="{}"></swal>
+<swal [swalOptions]="{}"></swal>

From now on, all new @Inputs that are not direcly native SweetAlert2 options will be prefixed by swal*.

You can see that there's already a new one: [swalDismissOnDestroy] (and its SweetAlert2Module counterpart of the same name)! Previously, you couldn't choose whether to keep a modal opened if its controlling <swal> component was destroyed by Angular (ex. after router navigation). Now you can!

Replace direct sweetalert2 imports and .nativeSwal usages

⚠️ Do NOT import sweetalert2 directly anymore if you used to do that, unless you know what you're doing. That would prevent Webpack (Angular CLI) to achieve code splitting and load SweetAlert2 lazily, and it would be included in the main bundle.

Instead, use our new SweetAlert2LoaderService.

  1. SwalComponent.nativeSwal has been removed:
-import { SwalComponent } from '@sweetalert2/ngx-sweetalert2';
+import { SweetAlert2LoaderService } from '@sweetalert2/ngx-sweetalert2';

@Component({})
export class AppComponent {
-    // remove it if you used @ViewChild just to get a .nativeSwal reference
-    @ViewChild('mySwal', { static: true })
-    public mySwal!: SwalComponent;
    
+    public constructor(private readonly sweetAlert2Loader: SweetAlert2LoaderService) {
+    }
    
-    public doSomething() {
+    public async doSomething() {
-        this.mySwal.nativeSwal.xxx();
+        const swal = await this.sweetAlert2Loader.swal;
+        swal.xxx();
    }
}
  1. For people that used sweetalert2 directly:
+import { SweetAlert2LoaderService } from '@sweetalert2/ngx-sweetalert2';
-import swal from 'sweetalert2';

@Component({})
export class AppComponent {
+    public constructor(private readonly sweetAlert2Loader: SweetAlert2LoaderService) {
+    }

-    public doSomething() {
+    public async doSomething() {
+        swal.xxx();
+        const swal = await this.sweetAlert2Loader.swal;
-        swal.xxx();
    }
}

"Partials" renamed to "Portals"

Here, the change should be simple for most of y'all:

-import { SwalPartialTargets } from '@sweetalert2/ngx-sweetalert2';
+import { SwalPortalTargets } from '@sweetalert2/ngx-sweetalert2';

@Component({})
export class AppComponent {
-    public constructor(public readonly swalTargets: SwalPartialTargets) {
+    public constructor(public readonly swalTargets: SwalPortalTargets) {
    }
}
<swal>
-    <ng-container *swalPartial="swalTargets.title">
+    <ng-container *swalPortal="swalTargets.title">
        Hello, <strong>{{ username }}</strong>
    </ng-container>
</swal>

⚠️ Some targets have been removed, the targets' behaviour slightly changed, and the area targeted by the default target, content, is now slightly different too.

Don't miss a new ngx-sweetalert2 release

NewReleases is sending notifications on new releases.