Difficulty: Moderate
Dojo version: 1.7 +
Author: Dylan schiann
By nate (supnate@gmail.com)
Link: http://www.sitepen.com/blog/2012/08/27/working-with-dojo-and-amd-in-production/
In recent articles, we have demonstrated how to use nested require to use layer files packaged through the dojo build system. Here, layer is a term in Dojo. A layer is a file that contains many JavaScript resources, that is, a packaged file. This reduces the number of requests in the production environment and increases the page loading speed.
We first introduced the layer file using the following statement:
<script type="text/javascript" src="../../dojo/dojo.js" data-dojo-config="async: true"></script><script type="text/javascript"> require(['dgrid/dgrid'], function () { require(["dgrid/List", "dgrid/OnDemandGrid","dgrid/Selection", "dgrid/Keyboard", "dojo/_base/declare", "dgrid/test/data/perf", "dojo/domReady!"], function(List, Grid, Selection, Keyboard, declare, testPerfStore){ //...
Such writing can certainly work, but it is not perfect. Because you need to modify the source file when deploying the final application after building. Introducing a layer is not the same as require a common amd module during development. Although you can use PHP or some server-side languages to generate such JavaScript files, there are many other alternatives. Here we will look at the following five methods:
Method 1: single-layer builds
Applicable to: simple, fast, and single-layer applications
In our initial article, we focused on how to build a simple and mini package. In the current scenario, you may need to create a custom dojo. js that contains all the modules you need. In this way, all required modules can be loaded at one time in the require of the page. We do not need to require a layer in advance, because all required modules have been loaded through dojo. js.
Method 2: introduce different modules based on URLs
Applicable to: simple and quick introduction module based on URL format
This method determines which modules the application should load based on the URL. For example, we can determine whether the URL contains the word Dev, so that an additional module can be introduced only in non-development environments, that is, the packaged layer.
require(/dev/.test(location.search) ? [] : ['dgrid/dgrid'], function(){ require(["dgrid/List", "dgrid/OnDemandGrid","dgrid/Selection", "dgrid/Keyboard", "dojo/_base/declare", "dgrid/test/data/perf", "dojo/domReady!"], function(List, Grid, Selection, Keyboard, declare, testPerfStore){ //... });});
Method 3: Configure deps and callback of a Layer
Applicable to: loading the corresponding module based on the URL or dojoconfig settings.
In the global configuration of dojo, you can set the dojoconfig. deps attribute to load a layer. After the layer is loaded, dojoconfig. Callback is automatically called, where the application startup logic can be placed.
<script type="text/javascript">var dojoConfig = { async: 1, deps: ['dgrid/dgrid'], callback: function(){ require(["dgrid/List", "dgrid/OnDemandGrid","dgrid/Selection", "dgrid/Keyboard", "dojo/_base/declare", "dgrid/test/data/perf", "dojo/domReady!"], function(List, Grid, Selection, Keyboard, declare, testPerfStore){ //... }); }};</script></script type="text/javascript" src="../../dojo/dojo.js"></script>
After all the dependent modules are loaded, a callback function is executed, which is defined in the dojoconfig object. In this case, we can also return the dependency Module Based on the URL, which is similar to the previous example.
<script>var dojoConfig = { async: 1, deps: /dev/.test(location.search) ? [] : ['dgrid/dgrid'], callback: function(){ require(["dgrid/List", "dgrid/OnDemandGrid","dgrid/Selection", "dgrid/Keyboard", "dojo/_base/declare", "dgrid/test/data/perf", "dojo/domReady!"], function(List, Grid, Selection, Keyboard, declare, testPerfStore){ //... }); }};</script></script type="text/javascript" src="../../dojo/dojo.js"></script>
This method can be used to flexibly control dojoconfig. deps. You can give a URL or a global variable. We can even use the dependent module as the return value of the function, so that we can more flexibly decide what type of module the application should load.
This flexible method allows us to switch between development, testing, and production environments freely.
Method 4: top-level modules
Applicable to: large applications with many modules
Another common method for smoothing between the development environment and the production environment is to create a top-level module to introduce the required modules for a page in this top-level module. In this way, you can specify this top-level module for a layer in the dojo build tool. Therefore, the development environment and production environment only need to load the same module in HTML. Another benefit of this method is that it ensures that JavaScript code is not included in HTML, making it easier to maintain.
For example, you may have defined a module: APP/APP. js
define(["dgrid/List", "dgrid/OnDemandGrid","dgrid/Selection", "dgrid/Keyboard", "dojo/_base/declare", "dgrid/test/data/perf", "dojo/domReady!"], function(List, Grid, Selection, Keyboard, declare, testPerfStore){ //...});
Then, your HTML only needs to contain the following simple code:
<script>var dojoConfig = { async: true, deps: ["app/app"]};</script><script src="dojo/dojo.js"></script>
Method 5: dojo template project
Applicable to: a fairly automatic method based on dojo build Best Practices
The dojo boilerplate project will automatically process your scenario. It creates some common dojo application architectures for reference and contains some automatic build scripts to help you transition from the development environment to the production environment.
Conclusion
To sum up, there are many ways to use AMD and dojo layers in the production environment. You can make appropriate choices based on your needs. Of course, if you have some other good ideas or questions, please comment on them.