Detailed introduction to UMD specification in javascript (with code)

This article brings you a detailed introduction to the UMD specification in javascript (with code). It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.

1. UMD specification

Address: https://github.com/umdjs/umd

UMD specification is the ugliest one among all specifications, there is no one! ! ! It appears to make the module compatible with both AMD and CommonJs specifications. It is mostly used by some third-party libraries that need to support both browser-side and server-side references. UMD is a product of an era. When various environments finally realize the unified specifications of ES harmony, it will also withdraw from the stage of history.

The structure of the UMD specification is very complicated at first glance, mainly because you need some basic knowledge of javascript to understand this paradigm. Its basic structure is as follows:

(function (root, factory) {
    if (typeof define === 'function' && define.amd) {
        // AMD
        define(['jquery', 'underscore'], factory);
    } else if (typeof exports === 'object') {
        // Node, CommonJS之类的
        module.exports = factory(require('jquery'), require('underscore'));
    } else {
        // 浏览器全局变量(root 即 window)
        root.returnExports = factory(root.jQuery, root._);
    }
}(this, function ($, _) {
    //    方法
    function a(){};    //    私有方法，因为它没被返回 (见下面)
    function b(){};    //    公共方法，因为被返回了
    function c(){};    //    公共方法，因为被返回了

    //    暴露公共方法
    return {
        b: b,
        c: c
    }
}));

2. Source code Paradigm deduction

2.1 Basic structure

Let’s first look at the outermost structure:

(function (){}());

It is very simple, it is a self-executing function. Since it is a modular standard, it means that this self-executing function can eventually export a module. From a code perspective, there are actually two common implementation methods:

1. return returns a module;

2. The actual parameters are passed in an object, and the things that are generated within the function and need to be exported are hung on the properties of this object;

It can be seen that there is no return statement inside the function body above, so we can guess that UMD adopts the second method when implementing it. Since UMD is a modular specification, its function is to produce modules according to usage requirements, which means that its responsibility is called a module factory. We can define a factory method, and whenever this method is executed, a module, so its basic structure becomes as follows:

(function (factory){
    //假设没有使用任何模块化方案，那么将工厂函数执行后返回的内容直接挂载到全局
    window.Some_Attr = factory（）;
}(function(){
    //自定义模块主体的内容
    /*
        var a,b,c
        function a1(){}
        function b1(){}
        function c1(){}
        return {
           a:a1,
           b:b1
        }
     */
}))

That is to say, we customize an anonymous function, and then pass it as an actual parameter to the self-executing function, and then execute it in the This factory method is accessed through formal parameters inside the function (or you will be more familiar with the callback function or callback), and it is simply hung on the global object, thus completing the basic module export.

Sometimes we also hope to mount the module into a non-global environment. Dynamically passing the mounting object in can make the code more flexible. This involves a basic knowledge, which is the browser environment. The global object in has three attributes: parent, top, and self to track the new Window object introduced after embedding "iframe" in the page. The single-page Window.self points to itself. It is often identified in the code by whether it contains the self attribute. Global object, so the writing method here can be improved to be compatible:

(function(root,factory){
    root.Some_Attr = factory();
}(self !== undefined ? self : this, function(){
    
}));

2.2 Adaptation to AMD

Then let’s first add AMD’s standard adaptation, standard address: AMD standard github address:

/*
* AMD规范的模块定义格式是define(id?, dependencies?, factory),factory就是实际的模块内容
*/
(function (factory){
    //判断全局环境是否支持AMD标准
    if(typeof define === 'function' && define.amd){
        //定义一个AMD模块
        define([/*denpendencies*/],factory);
    }
}(function(/*formal parameters*/){
    //自定义模块主体的内容
    /*
        var a,b,c
        function a1(){}
        function b1(){}
        function c1(){}
        return {
           a:a1,
           b:b1
        }
     */
}))

2.3 Adapting CommonJs

Then let’s first add the standard adaptation of

CommonJs:

/*
* CommonJs规范使用require('moduleName')的格式来引用模块，使用module.exports对象输出模块，所以只要把模块的输出内容挂载到module.exports上就完成了模块定义。
*/
(function (factory){
    //判断全局环境是否支持CommonJs标准
      if(typeof exports === 'object' && typeof define !== 'function'){
             module.exports = factory(/*require(moduleA), require(moduleB)*/);
      }
}(function(/*formal parameters*/){
    //自定义模块主体的内容
    /*
        var a,b,c
        function a1(){}
        function b1(){}
        function c1(){}
        return {
           a:a1,
           b:b1
        }
     */
}))

Add the adaptation to

CommonJs## After the adaptation of #, the return content (usually an object) in the function body is mounted on module.exports. If you have written node.js code, for This will certainly not be unfamiliar. Crush the above fragments together, and you will understand what

UMD

looks like. 3. A more targeted UMD paradigm

UMD provides a more targeted paradigm on its github homepage, which is suitable for different scenarios. Interested readers can check it out by themselves ( The address is given in Section 1).

Here is a jqueryPlugin development paradigm that may be useful to most developers. If you understand the above analysis, the following code should not be difficult to understand:

// Uses CommonJS, AMD or browser globals to create a jQuery plugin.
(function (factory) {
    if (typeof define === 'function' && define.amd) {
        // AMD. Register as an anonymous module.
        define(['jquery'], factory);
    } else if (typeof module === 'object' && module.exports) {
        // Node/CommonJS
        module.exports = function( root, jQuery ) {
            if ( jQuery === undefined ) {
                // require('jQuery') returns a factory that requires window to
                // build a jQuery instance, we normalize how we use modules
                // that require this pattern but the window provided is a noop
                // if it's defined (how jquery works)
                if ( typeof window !== 'undefined' ) {
                    jQuery = require('jquery');
                }
                else {
                    jQuery = require('jquery')(root);
                }
            }
            factory(jQuery);
            return jQuery;
        };
    } else {
        // Browser globals
        factory(jQuery);
    }
}(function ($) {
    $.fn.jqueryPlugin = function () { return true; };
}));

4. Modular development

Front-end modularization itself is a slightly confusing topic. The author himself was initially confused about require() and require.js, but modularization is very important in front-end development. If you don’t want to just write code on one page for the rest of your life, you must pass this level. Interested readers can study in chunks according to the basic categories below.

The above is the detailed content of Detailed introduction to UMD specification in javascript (with code). For more information, please follow other related articles on the PHP Chinese website!