Seriously? You added a "x" into the package name?? And now I'm loosing time with that.

Yes, and I'm sorry for that. But ngx- prefixes are now a community convention (that really began to spread after I named that package). I think that this new name will increase the package visibility and instantly inform aware Angular users that this package is only for newer Angulars (not AngularJS 1.x).

But also, this is our v3.0.0 release, that brings nice improvements over NgSweetAlert2 v2.x, while being mostly backward-compatible (you probably won't have any code to change except your imports).

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

So what has changed apart that?

There's a bunch of new features! And mainly, a deeper integration with Angular and SweetAlert2. While NgSweetAlert2 was a wrapper for swal() calls, ngx-sweetalert2 keeps the same base but allows much more things.

But let's see the breakdown of the changes:

:arrow_double_up: SweetAlert2 v.7

The minimal SweetAlert2 version required now is SweetAlert2 v.7. If you weren't directly using swal() but just NgSweetAlert2, you'll have nothing to change! ngx-sweetalert2 handles the plumbing changes for you.

Also, you were likely importing SweetAlert's CSS stylesheet (node_modules/sweetalert2/dist/sweetalert2.css). Remove that import, SweetAlert2 handles that for you now, and injects styles dynamically :raised_hands:

:link: Strong dependency on SweetAlert2's minor versions

The new ng-sweetalert2 reuses the types of the members of the SweetAlertOptions TypeScript interface from SweetAlert2.

In practice, this means: don't update ngx-sweetalert2 without upgrading sweetalert2 before, in the case we use types that aren't yet defined in your SweetAlert2 version. You can however upgrade sweetalert2 minor versions without upgrading ngx-sweetalert2.

If there's an incorrect version of SweetAlert2, npm or yarn will tell you that the peerDependency isn't met. Pay attention to those messages in general.

:package: Better build artifacts

The build system has been completely revised. Before, I had a custom setup that wasn't very bullet-proof or practical to use. The new one is based on ng-packagr so the library is distributed in Angular Package Format and should be more portable.

That shouldn't change anything for you if you were consuming the package normally (import { SweetAlert2Module } from '@toverux/ngsweetalert2';, ie. you don't override the library's entry path).

:heavy_plus_sign: SwalDirective [swal]

Backward-compatible, it still take an object of SweetAlert2 options in it and still has its event emitters.

<button #btn [swal]="['Oops!', 'This is not implemented yet :/', 'warning']" (cancel)="btn.innerText = 'Dont click me'">
  Click me
</button>

But you can now also pass a SwalComponent reference (<swal #mySwal>) to it:

-<button (click)="mySwal.show()">
+<button [swal]="mySwal">

<swal #mySwal></swal>

Also, under the hood when no exisiting <swal> is passed, it creates one dynamically, to avoid different behaviours and enable code reuse between the component and the directive.

:heavy_plus_sign: SwalComponent <swal>

Backward-compatible. But it also adds a buch of @Input()s that have 1:1 mapping with SweetAlert2 options. You still have the possibility to pass custom/future options through [options].

<swal 
  #deleteSwal
  title="Delete {{ file.name }}?"
  text="This cannot be undone"
  type="question"
  [showCancelButton]="true"
  [focusCancel]="true"
  (confirm)="deleteFile(file)">
</swal>

<button [swal]="deleteSwal">Delete {{ file.name }}</button>

It also have now @Output()s for the modal lifecycle events: (beforeOpen), (open), (close).

See the readme for more.

:heavy_plus_sign: SwalPartialDirective *swalPartial – :star: New!

This one really pushes the Angular integration further and makes ngx-sweetalert2 much more useful since it's no longer just a wrapper for declarative SweetAlerts. It allows you to do what's not easy to do with native SweetAlert2: dynamic content in the modal.

You can now use the full power of the Angular Templating Language, data binding, change detection, etc, inside the alerts. Before, you would have ended up with complex DOM manipulations in your component, now it's properly supported and not even hacky:

<swal title="Fill the form, rapidly" (open)="startCountdown()">
  <!-- This form will be displayed as the alert main content
       Targets the alert's main content zone by default -->
  <form *swalPartial [formControl]="myForm">
    ...
  </form>
        
  <!-- This targets the confirm button's inner content
       Notice the usage of ng-container to avoid creating an useless DOM element inside the button -->
  <ng-container *swalPartial="swalTargets.confirmButton">
    Send ({{ countdownSecondsLeft }} seconds left)
  </ng-container>
<swal>

Find more in the readme.

2.0.1 (2017-10-11)

Bug Fixes

• SwalDirective: stop propagation of click event to parent handlers (#28) (5445f3b)

2.0.0 (2017-10-10)

The APIs of SwalComponent and SwalDirective haven't changed. However, you now have to install SweetAlert2 as a direct dependency, and possibly change the way you import the NgSweetAlert2Module.

Bug Fixes

• SweetAlert2Module: remove forced SwalDefaults provider on every module instance (9370413)

Features

• package: SweetAlert2 is now a peer dependency (00ee2d5)

BREAKING CHANGES

• package: SweetAlert2 is now a peer dependency: if you haven't specified sweetalert2 in your direct dependencies yet, do it now!
• SweetAlert2Module: Users that weren't using .forRoot() will now need to add it. Users that were using submodules won't need to repeat .forRoot() calls in these submodules - they will now inherit ther options from the parent forRoot()'ed SweetAlert2Module.

Upgraded a few packages, and made the version requirement for Angular compatible with Angular 4. No changes to the codebase were necessary.

This lets you configure default SweetAlert options that will apply for every modal.