Why swal.fire?

[WillGoldstein]

Just wondering, why the addition of a breaking change like .fire which seems completely unnecessary at first glance?

[zenflow]

We migrated the code-base to be object-oriented (i.e. we changed the swal function into the Swal class). Therefore to instantiate a swal you would need to now use the new keyword, e.g. new Swal({...options}) instead of just Swal({...options}).

The problem with this is that you do nothing with the result of the call (the instance) you will be violating the eslint "no-new" rule, which is a common rule to be enabled, and part of JavaScript Standard Style.

function sayHi () {
  new Swal('Hi') // violates the eslint "no-new" rule
}

The Swal.fire static method behaves the exact same as the constructor (takes the same arguments, and returns an instance) but does not have this problem.

function sayHi () {
  Swal.fire('Hi') // does not violate the eslint "no-new" rule
}

related: When we did most of the OO refactoring during version 7, we used a hack to allow instantiation without the new keyword, to maintain backwards-compatibility (i.e. you could still instantiate a swal with Swal({...options})) but we dropped that for version 8. See issue #1368.

[WillGoldstein]

Thanks @zenflow , appreciate the thorough explanation.

[zenflow]

@WillGoldstein No problem.. this should also serve other people wondering the same thing

[nafg]

To be clear, will Swal(...) work just usually have a lint error so the fire method was added, or does it not work and .fire is mandatory?

Also, why not include a (lowercase) swal method for backwards-compatibility and mark it deprecated? Or did you?

[limonte]

To be clear, will Swal(...) work just usually have a lint error so the fire method was added, or does it not work and .fire is mandatory?

.fire() is mandatory.

Also, why not include a (lowercase) swal method for backwards-compatibility and mark it deprecated? Or did you?

It is included

Please read the release notes for more info: https://github.com/sweetalert2/sweetalert2/releases/tag/v8.0.0

[nafg]

Wait, the lowercase version is a synonym for the class? I'm confused, is it a breaking change or did you make the lowercase be backwards-compatible?

…

On Mon, Jun 17, 2019, 3:22 AM Limon Monte ***@***.***> wrote: To be clear, will Swal(...) work just usually have a lint error so the fire method was added, or does it not work and .fire is mandatory? .fire() is mandatory. Also, why not include a (lowercase) swal method for backwards-compatibility and mark it deprecated? Or did you? It is included [image: image] <https://user-images.githubusercontent.com/6059356/59585703-cc3f7000-90e9-11e9-8a32-60b73cbff810.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1438?email_source=notifications&email_token=AAAYAUED4PRZRVYW4DWWSBDP243URA5CNFSM4G4H2XFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX2ITXQ#issuecomment-502565342>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAYAUD43AJ7Y6D3B2BQHNTP243URANCNFSM4G4H2XFA> .

[limonte]

The lowercase is there for backwards-compatibility, yes. But it is recommended to use Swal instead of swal.

[bigabdoul]

@WillGoldstein You can use the following in your top-level script (just under the sweetalert2 library) to preserve code that rely on the legacy swal(...) syntax:

if (window.Swal && typeof window.Swal.fire === "function") {
    const original = window.swal;
    window.swal = function () {
        window.Swal.fire.call(original, ...arguments);
    };
}

I hope this helps.