The alert.js file, written in ECMAScript 2015 syntax (also known as ES6, the latest (at the time of writing) standardized specification of JavaScript), first imports a utilities module:

    import Util from './util'

A constant is then created, named Alert, which is assigned the result of an Immediately Invoked Function Expression (IIFE):

    const Alert = (($) => {
    ...
    })(jQuery)

A jQuery object is being passed into a function for execution, the result of which will be assigned to the immutable Alert constant.

Within the function itself, a number of constants are also declared for use throughout the rest of the code. Declaring immutables at the beginning of the file is generally seen as best practice. Observe the following code:

    const NAME                = 'alert'
    const VERSION             = '4.0.0-alpha'
    const DATA_KEY            = 'bs.alert'
    const EVENT_KEY           = '.${DATA_KEY}'
    const DATA_API_KEY        = '.data-api'
    const JQUERY_NO_CONFLICT  = $.fn[NAME]
    const TRANSITION_DURATION = 150
    
    const Selector = {
      DISMISS : '[data-dismiss="alert"]'
    }
    const Event = {
      CLOSE : 'close${EVENT_KEY}',
      CLOSED : 'closed${EVENT_KEY}',
      CLICK_DATA_API : 'click${EVENT_KEY}${DATA_API_KEY}'
    }
    
    const ClassName = {
      ALERT : 'alert',
      FADE : 'fade',
      IN : 'in'
    }

The NAME property is the name of the plugin, and VERSION defines the version of the plugin, which generally correlates to the version of Bootstrap. DATA_KEY, EVENT_KEY, and DATA_API_KEY relate to the data attributes that the plugin hooks into, while the rest are coherent, more readable, aliases for the various values used throughout the plugin code. Following that is the class definition.

(function(args){ })(args)
!function(args){ }(args)

Near the top of any of the plugin JS files, you will see a comment declaring the beginning of the class definition for that particular plugin. In the case of alerts, it is:

    /**
    * -------------------------------------------------------------------
    -----    
    * Class Definition
    * -------------------------------------------------------------------
    -----
    */

The class definition is simply the constructor of the base object, in this case, the Alert object:

    class Alert {
        constructor(element) {
            this._element = element
        }
        ...
    }

The convention with plugins is to use Prototypal inheritance. The Alert base object is the object all other Alert type objects should extend and inherit from. Within the class definition, we have the public and private functions of the Alert class. Let's take a look at the public close function:

    close(element) {
        element = element || this._element
        let rootElement = this._getRootElement(element)
        let customEvent = this._triggerCloseEvent(rootElement)
        if (customEvent.isDefaultPrevented()) {
          return
        }
        
        this._removeElement(rootElement)
    }

The close function takes an element as an argument, which is the reference to the DOM element the close function is to act upon. The close function uses the private function _getRootElement to retrieve the specific DOM element, and _triggerCloseEvent to reference the specific event to be processed. Finally, close calls _removeElement. Let's take a look at these private functions:

    _getRootElement(element) {
        let selector = Util.getSelectorFromElement(element)
        let parent   = false
        
        if (selector) {
            parent = $(selector)[0]
        }
        
        if (!parent) {
            parent = $(element).closest(`.${ClassName.ALERT}`)[0]
        }
        return parent
    }

The _getRootElement tries to find the parent element of the DOM element passed to the calling function, in this case, close. If a parent does not exist, _getRootElement returns the closest element with the class name defined by ClassName.ALERT in the plugin's initial setup. This in our case is Alert. Observe the following code:

    _triggerCloseEvent(element) {
        let closeEvent = $.Event(Event.CLOSE)
        $(element).trigger(closeEvent)
        return closeEvent
    }

The _triggerCloseEvent also takes an element as an argument and triggers the event referenced in the plugin's initial setup by Event.CLOSE:

    _removeElement(element) {
        $(element).removeClass(ClassName.IN)
        if (!Util.supportsTransitionEnd() ||
            !$(element).hasClass(ClassName.FADE)) {
          this._destroyElement(element)
          return
        }
        $(element)
            .one(Util.TRANSITION_END, $.proxy(this._destroyElement,
            this, element))
            .emulateTransitionEnd(TRANSITION_DURATION)
    }

The _removeElement then carries out the removal of the rootElement safely and in accordance with the configuration in the element itself, or as defined in the plugin's initial setup, for example, TRANSITION_DURATION.

All core behaviors and functions of the plugin should be defined in the same manner as the close function. The class definition represents the plugin's essence.

After the public and private functions come the static functions. These functions, which are also private, are similar to what would be described as the plugin definition in Bootstrap 3. Observe the following code:

    static _jQueryInterface(config) {
        return this.each(function () {
            let $element = $(this)
            let data = $element.data(DATA_KEY)
            if (!data) {
                data = new Alert(this)
                $element.data(DATA_KEY, data)
            }
            if (config === 'close') {
                data[config](this)
            }
        })
    }
    static _handleDismiss(alertInstance) {
        return function (event) {
            if (event) {
                event.preventDefault()
            }
            alertInstance.close(this)
        }
    }

The _jQueryInterface is quite simple. First, it loops through an array of DOM elements. This array is represented here by the this object. It creates a jQuery wrapper around each element and then creates the Alert instance associated with this element, if it doesn't already exist. _jQueryInterface also takes in a config argument. As you can see, the only value of config that _jQueryInterface is concerned with is 'close'. If config equals 'close', then the Alert will be closed automatically.

_handleDismiss simply allows for a specific instance of Alert to be programmatically closed.

Following the class definition, we have the data API implementation.

The role of the data API implementation is to create JavaScript hooks on the DOM, listening for actions on elements with a specific data attribute. In alert.js, there is only one hook:

    $(document).on(
        Event.CLICK_DATA_API,
        Selector.DISMISS,
        Alert._handleDismiss(new Alert())
    )
    $(document).on('click.bs.alert.data-api', dismiss,
    Alert.prototype.close)

The hook is an on-click listener on any element that matches the dismiss selector.

When a click is registered, the close function of Alert is invoked. The dismiss selector here has actually been defined at the beginning of the file, in the plugin setup:

    const Selector = {
        DISMISS : '[data-dismiss="alert"]'
    }

Therefore, an element with the attribute data-dismiss="alert" will be hooked in, to listen for clicks. The click event reference is also defined in the setup:

    const Event = {
        CLOSE          : 'close${EVENT_KEY}',
        CLOSED         : 'closed${EVENT_KEY}',
        CLICK_DATA_API : 'click${EVENT_KEY}${DATA_API_KEY}'
    }

EVENT_KEY and DATA_API_KEY, if you remember, are also defined here:

    const DATA_KEY             = 'bs.alert'
    const EVENT_KEY          = '.${DATA_KEY}'
    const DATA_API_KEY     = '.data-api'

We could actually rewrite the API definition to read as follows:

    $(document).on('click.bs.alert.data-api', '[data-dismiss="alert"]', 
    Alert._handleDismiss(new Alert()))

The last piece of the puzzle is the jQuery section, which is a new feature in Bootstrap 4. It is a combination of Bootstrap 3's plugin definition and a conflict prevention pattern.

The jQuery section is responsible for adding the plugin to the global jQuery object so that it is made available anywhere in an application where jQuery is available. Let's take a look at the code:

    $.fn[NAME]             = Alert._jQueryInterface
    $.fn[NAME].Constructor = Alert
    $.fn[NAME].noConflict  = function () {
        $.fn[NAME] = JQUERY_NO_CONFLICT
        return Alert._jQueryInterface
    }

The first two assignments extend jQuery's prototype with the plugin function. As Alert is created within a closure, the constructor itself is actually private. Creating the Constructor property on $.fn.alert allows it to be accessible publicly.

Then, a property of $.fn.alert called noConflict is assigned the value of Alert._jQueryInterface. The noConflict property comes into use when trying to integrate Bootstrap with other frameworks to resolve issues with two jQuery objects with the same name. If in some framework the Bootstrap Alert got overridden, we could use noConflict to access the Bootstrap Alert and assign it to a new variable:

    $.fn.bsAlert = $.fn.alert.noConflict()

$.fn.alert is the framework version of Alert, but we have transferred the Bootstrap Alert to $.fn.bsAlert.

All plugins tend to follow the pattern of initial setup, class definition, data API implementation, and jQuery extension. To accompany the JavaScript, a plugin also has its own specific Sass style sheet.