Introduction détaillée à la spécification UMD en javascript (avec code)

Cet article vous apporte une introduction détaillée à la spécification UMD en javascript (avec code). Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

1. Spécification UMD

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

La spécification UMD est la plus moche parmi toutes les spécifications, il n'y en a pas ! ! ! Il semble que le module soit compatible avec les spécifications AMD et CommonJs. Il est principalement utilisé par certaines bibliothèques tierces qui doivent prendre en charge les références côté navigateur et côté serveur. L'UMD est le produit d'une époque. Lorsque les différents environnements réaliseront enfin les spécifications unifiées de l'harmonie ES, il se retirera également de la scène de l'histoire.

La structure de la spécification UMD est très compliquée à première vue, principalement parce que vous avez besoin de connaissances de base en javascript pour comprendre ce paradigme. Sa structure de base est la suivante :

(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. .Déduction du paradigme du code source

2.1 Structure de base

Regardons d'abord la structure la plus externe :

(function (){}());

C'est très simple, c'est une fonction auto-exécutable. Puisqu'il s'agit d'un standard modulaire, cela signifie que cette fonction auto-exécutable peut éventuellement exporter un module Du point de vue du code, il existe en fait deux méthodes d'implémentation courantes :

1. retour. renvoie un module ;

2. Les paramètres réels sont passés dans un objet, et les éléments générés à l'intérieur de la fonction et qui doivent être exportés sont suspendus aux propriétés de cet objet <🎜 ; >

Vous pouvez voir qu'il n'y a pas d'instruction return dans le corps de la fonction ci-dessus, nous pouvons donc deviner que UMD adopte la deuxième méthode lors de son implémentation. Puisque UMD est une spécification modulaire, sa fonction est de produire des modules en fonction des exigences d'utilisation, ce qui signifie que sa responsabilité est appelée une fabrique de modules. Nous pouvons définir une méthode de fabrique, et chaque fois que cette méthode est exécutée, un module, donc sa structure de base. devient le suivant :

C'est-à-dire que nous personnalisons une fonction anonyme, puis la passons comme paramètre réel à la fonction auto-exécutable, puis accédons à cette méthode d'usine via des paramètres formels à l'intérieur du fonction auto-exécutable (ou vous serez plus familier avec les fonctions de rappel ou les rappels), et accrochez-la simplement à l'objet global, complétant ainsi l'exportation du module de base.

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

Parfois, nous espérons également monter le module dans un environnement non global. Le passage dynamique de l'objet de montage peut rendre le code plus flexible. Cela implique des connaissances de base, à savoir l'environnement du navigateur. trois attributs : parent, top et self pour suivre le nouvel objet Window introduit après l'intégration de "iframe" dans la page. La page unique Window.self pointe vers elle-même, et elle est souvent identifiée dans le code selon qu'elle contient ou non l'attribut self. . Objet global, donc la méthode d'écriture ici peut être améliorée pour être compatible :

2.2 Adaptation à AMD

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

Ajoutons ensuite d'abord l'adaptation de la spécification AMD, adresse de spécification : Spécification AMD. Adresse github :

2.3 Adaptation de CommonJs

/*
* 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
        }
     */
}))

Ajoutons d'abord l'adaptation standard de

 :

CommonJs

Ajoutez l'adaptation à

/*
* 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
        }
     */
}))

Après adaptation, le contenu de retour dans le corps de la fonction (généralement un objet) est monté sur

Si vous avez écrit du code CommonJs, vous le connaîtrez. module.exportsnode.jsÉcrasez les fragments ci-dessus ensemble et vous comprendrez à quoi

ressemble.

UMD3. Un paradigme UMD plus ciblé

UMD propose un paradigme plus ciblé sur sa page d'accueil github, qui convient à différents scénarios. Les lecteurs intéressés peuvent le consulter par eux-mêmes (l'adresse est indiquée). dans la section 1).

Publiez ici un paradigme de développement jqueryPlugin qui peut être utile à la plupart des développeurs Si vous comprenez l'analyse ci-dessus, le code suivant ne devrait pas être difficile à comprendre :

4. . Développement modulaire

// 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; };
}));

La modularisation front-end elle-même est un sujet légèrement déroutant. Au départ, l'auteur lui-même ne pouvait pas faire la différence entre require() et require.js, mais la modularisation est une partie importante du développement front-end. C'est un sujet très important. Si vous ne voulez pas écrire du code sur une seule page pour le reste de votre vie, vous devez réussir ce niveau. Les lecteurs intéressés peuvent l'étudier en morceaux selon les catégories de base ci-dessous.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!