javascript - requirejs define: nested dependency -


i'd define a, should require b , b require c (for sake of r.js)

any of these 2 correct?

define([     'module' ], function(module) {     require(['c'], function() {         require(['b'], function() {              var a;              return a;         });     }); });   require(['c'], function() {     require(['b'], function() {         define([             'module'         ], function(module) {             var a;              return a;         });     }); }); 

neither of choices correct.

you first choice attempts use return return value asynchronous callback. not possible, , requirejs no different. see this question , answers why way.

your second choice puts define inside callback passed require. may work in toy cases in general won't work. (by "toy case" mean proof-of-concepts conditions under tight control. such cases not reflect realities of real applications.)

linh pham's suggestion option here:

define(["module", "b", "c"], function(module){     var a;      return a; }); 

and if b depends on c , not amd library, put shim it. in comment objected you'd have have "hundreds" of shims if did this. have few options avoid these shims:

  1. do not load c requirejs. load script element before requirejs loaded on page.

  2. design application started 1 module , require application started loading c before else:

    require(['c'], function () {     require(['main']); }); 

    main module starts application. disadvantage of method if me, eventually, going forget require c before require main.


Comments

Popular posts from this blog

javascript - AngularJS custom datepicker directive -

javascript - jQuery date picker - Disable dates after the selection from the first date picker -