requirejs: path when the module is loaded (the require) and definitions (DEFINE) understood

To the new intern at JS popularity of the basics, see good article

Reprinted https://blog.csdn.net/xuxiaoping1989/article/details/52384778

Contact requirejs of children's shoes may know, whether it is defined by the module define, or to load modules require, module dependent statement is a very important step. Of which related to the module path resolution, for the novice, sometimes people will feel very confused.

We assume that the directory structure is as follows:

demo.html 
js/require.js 
js/main.js 
js/lib.js                               =>alert('js/lib')
js/util.js                              =>alert('js/util')
js/common/lib.js              =>alert('s/common/lib')
js/common/jqury/lib.js    =>alert('js/common/jqury/lib')
common/lib.js                  =>alert('common/lib')

baseUrl: basic foundation of
the module's path resolution requirejs, baseUrl is a very basic concept, leaving it basically could not handle, so here briefly. Simply put, baseUrl specify a directory, then requirejs Based on this directory to find the dependent modules.
For chestnuts, loaded requirejs in demo.html years, a statement that data-main attribute on the script requirejs where, then, after requirejs loaded down, it will do two things:
1), to load JS / main.js
2) , baseUrl path specified for the data-main file is located, here js /

<script src="js/require.js" data-main="js/main.js"></script>

Then, the following dependence of the actual path of the module lib js / lib.js

  1.  
    require(['lib'], function(Lib){
  2.  
    // do sth
  3.  
    });

Of course, in addition to data-main attribute, you can manually configure baseUrl, such as the following example. It is emphasized that:
If there is no data-main attribute specifies baseUrl through, did not show config statement baseUrl by the way, so that the page is loaded by default baseUrl requirejs the path where the
index.html (index.html point where at this time of baseUrl path)

  1.  
    <script src="js/require.js"></script>
  2.  
    <script src="js/main.js"></script>

main.js

  1.  
    require(['js/lib'], function(lib){
  2.  
    <pre name= "code" class="html"><span style="white-space:pre"> </span>lib.lib() //'js/lib'

});

 


baseUrl + path: Let rely more concise, flexible,
for example, we loaded a bunch of the following modules (a lot of fruit ...), looking down a long list of dependency list, you might suddenly see the problem:
1), effortless: the front of each module has loaded long the Common / Fruits
2), difficult to maintain: maybe one day the directory name had changed (and is not rare in large-scale projects), imagine the directory structure to bring change workload

  1.  
    requirejs.config({
  2.  
    baseUrl: 'js'
  3.  
    });
  4.  
    // Load a bunch of fruit
  5.  
    require(['common/fruits/apple', 'common/fruits/orange', 'common/fruits/grape', 'common/fruits/pears'], function(Apple, Orange, Grape, Pears){
  6.  
    // do sth
  7.  
    });

For a module loader, the above said these two issues clearly need be taken into account. So requirejs authors provide paths this configuration item. We look at the revised code.

  1.  
    requirejs.config({
  2.  
    baseUrl: 'js'
  3.  
    paths: {
  4.  
    fruits: 'common/fruits'
  5.  
    }
  6.  
    });
  7.  
    // Load a bunch of fruit
  8.  
    require(['fruits/apple', 'fruits/orange', 'fruits/grape', 'fruits/pears'], function(Apple, Orange, Grape, Pears){
  9.  
    // do sth
  10.  
    });

In fact, it is less a common prefix, did not save much code, but when the project structure changes, the benefits it embodies. Assume common / fruits one day suddenly turned into a common / third-party / fruits, it is very simple, down paths change it.

    1.  
      requirejs.config({
    2.  
      baseUrl: 'js'
    3.  
      paths: {
    4.  
      fruits: 'common/third-party/fruits'
    5.  
      }
    6.  
      });
    7.  

Guess you like

Origin www.cnblogs.com/baitongtong/p/11611916.html