Enable and promote code reuse the fp way

Related to #815

The wrapper pattern

To reuse swal configuration, the promoted way is currently to use swal.setDefaults, but that method

1. stores configuration in global state, often making it harder to determine (by reading code) what defaults will be used
2. only supports having one configuration at a time
3. cannot merge configurations intelligently/dynamically. For example, if your reusable configuration uses onOpen and your instance configuration does too, the instance’s onOpen will take precedence and the reusable configuration will be effectively broken.

A better way is to use mixins, e.g. swal({ ...myPromptOptions, title: 'whats your name?' }) and swal({ ...myToastOptions, title: 'this is a toast' }). This does not have the 1st or 2nd issues from above, but it doesn’t help with the 3rd. Also this method is a bit verbose and not ergonomic in environments without object spread syntax (which is not yet implemented in Edge or Safari) where it looks more like swal(Object.assign({}, myPromptOptions, title: 'whats your name?' }).

Finally, if you want or need real extensibility, it is possible (almost! see Enable section). Behold:

// withCopyrightInFooter.js
export default (swal) => {
  const fn = (params) => {
    ...params,
    footer: (params.footer ? params.footer + '<br/>' : '') + 'Copyright Rick Sanchez'
  }
  Object.assign(fn, swal}
  return fn
}

// app.js
import swal from 'sweetalert2'
import withCopyrightInFooter from './withCopyrightInFooter'
const mySwal = withCopyrightInFooter(swal)
mySwal({title: 'Look! ', footer: 'This doesnt erase the copyright text'})

(edit: in the above code I changed swal(withCopyrightInFooter) to withCopyrightInFooter(swal)

As you can see, with this simple pattern, we gain a very robust extensibility. Not only can we add configuration pre-processing logic (i.e. fixes the 3rd issue above; we can merge configurations intelligently/dynamically), we can also extend the static methods (e.g. swal.enableButtons(), etc.), and transform the result value

Enable it

For the wrapper pattern to work, the swal function/object must have a consistent API/shape. Currently a bunch of methods are added after the first swal opens, but they don’t exist beforehand. I would assume this is not compatible with our .d.ts file. It’s a problem because these methods don’t exist at initialization, and thus they don’t get added to the child swal in the above example of the pattern. See PR #969.

Also it would be really nice if we could expose the currently internal logic for mapping shorthand arguments (i.e. swal(title, html, type) to a params object. This way we can use the shorthand with our composed mySwal objects and don’t need to duplicate the logic ourselves. Without this, the shorthand feature is likely to be discarded in many scenarios.

Promote it

We should deprecate swal.setDefaults and swal.clearDefaults and promote using mixins, or when robust extensibility is needed, the wrapper pattern.

We could and should also make the wrapper pattern easier to discover and use by adding an unintrusive convenience method!

[zenflow]

For one awesome example of what you can do with this pattern (though there are endless awesome examples possible), check out my WIP https://github.com/zenflow/sweetalert2-react-content ! Please open an issue! I’d like to get lots of review before transferring it to the sweetalert2 org and releasing 1.0.0!

[zenflow]

I was just going to demonstrate what I meant by “drop-in replacement”:

// before 
import swal from 'sweetalert2'
swal('using shorthand')
swal.clickConfirm() // using swal method

// after adding extension
import baseSwal from 'sweetalert2'
import withCopyrightInFooter from './withCopyrightInFooter'
const swal = withCopyrightInFooter(baseSwal)
swal('using shorthand')
swal.clickConfirm() // using swal method

It has the same API as the original, possibly extended with more methods/options/etc…