swal.disableConfirmButton() not working

I just noticed this does not work and throws a "ERROR TypeError: sweetalert2_1.default.disableConfirmButton is not a function"

To reproduce just create a new project with Angular CLI (I’m using version 1.6.6) and modify app.component.ts a bit:

import { Component } from '@angular/core';
import swal from 'sweetalert2';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent {
  title = 'app';

  constructor() {
    swal.disableConfirmButton();// <-- this doesn't work
    swal("sfsdfdsfd");// <-- this works fine
  }
}

[toverux]

Yes, those DOM-related functions are created after the first modal is shown. They do not set a state on which the button state is based: these are imperative DOM manipulations.

That’s why I use thunks here (see comment): https://github.com/sweetalert2/ngx-sweetalert2/blob/master/src/swal-partial-targets.ts#L3 (by the way, you just gave me a wonderful feature idea, thanks 😄).

You first need to request a modal in order to use disableConfirmButton(). You can use the onOpen hook to perform your call (onOpen is called before the modal is shown, but when its DOM is already created, therefore you won’t see the button “blink”):

swal({
  onOpen: () => swal.disableConfirmButton()
});

JSFiddle demo.

[zenflow]

I think this can be closed? Maybe one day we’ll have some kind of modal instances and not just utility function to manipulate the modals’ DOM, but this is another story.

@toverux @limonte It is possible to change the new context object to a class instance and move code into instance methods. In fact the only reason I didn’t do this in #969 was to avoid the huge code change that’s hard to review and can result in merge conflicts.