AMD modularization and local variable naming rules in Dojo

The robustness of client web application development has become stronger and stronger. There are many tools that can be used to enhance the immersion and interactive user experience of end customers. With the increase in the number of usersCodeIs particularly important. Using dojo and other amd-compatible tools makes it easy to write well-modularized front-end code. When AMD is used for development, developers can easily compile modular front-end code, but they need to face two problems, such as: 1. Rational naming module; 2. determine the corresponding naming rules for the local variables that reference a module.

First, review some amd technical terms:

Package

In short, the concept of a package is a set of modules, such as Dojo, dijit, and gridx. However, unlike various simple sets in the module directory, the package essentially includes some additional features, which can significantly enhance the portability and ease of use of the module.

The package mainly has three configuration options, including: name, package name; location, package location, which can be the relative path to the baseurl or absolute path; main, it is an optional parameter. The default value is "Main", which is used to find and correctly load the package that the module user tries to reference. For example, if you write require "dojo" in the Code, the actual file to be loaded is "dojo/Main. js ".

The management module is crucial because the number of dependencies of each package must be limited to a certain range. If one package depends on all other packages, it is difficult to use the package separately. The module also needs to be packaged in a meaningful way. For example, for the same package, do not include an operation module that contains the mathematical symbol pi or a display module of the Form Control.

Module

A module can make a class, a function, and an object that contains attributes and methods. It can also be just a piece of runable code. The function of the module is powerful and can be usedProgramAnd is easy to reuse.

The module name is automatically extracted from its file path name. For example, the file path of a module is art/shapes. JS, it will be referenced by the module by the name "Art/shapes. For more information about module naming, definitions, and references, see the amd API specification document.

The dojo loader simplifies the module redirection process. To reuse a module, you only need to copy the module file to the target path. For example, move the module File art/shapes. js to the module geometry to convert it into geometry/shapes. js. to reference this module, you only need to call the new module ID "Geometry/shapes ". As shown above, it is easy to move modules between different packages and make decoupling and code reuse easier.

The dojo loader allows the module to establish a ing relationship with the local variable name. It is extremely important for developers to select the variable name and packaging code. In the following two-minute introduction, we will explore more details in this field to benefit dojo developers.

How should I name a module?

When developing a module, appropriate naming rules can improve the development efficiency, ensure the module's API is clear and intuitive, and reduce the extra memory burden of the module name. In addition, it enables developers to spend more time on meaningful work, such as project optimization and defect fixing. When deciding on how to name a module, developers need to consider "whether it is a class constructor type" and "whether it is a Mixin type )", these things can change the naming rules recommended by the module.

If a module is a constructor type of a class, for example, a widget, it should be named in uppercamelcase. If a module is a Mixin ), it should follow the underscore (_ underscoremixin) format; if not, it should follow the lower ercamelcase naming format, a typical example is a monomer.

In addition to proper module naming, it is also a good habit to use the standard naming method for the variables mapped to the module when the callback function of require is used to reference the module. In dojo development, this work is called "preferred Arg alias", and some of them are recommended in Dojo. XX amd modules spreadsheet. This articleArticleIt is emphasized that the names of most modules must be accurate and meaningful. The preferred parameter alias of a module is similar to the module name. Even if the module name cannot be accurately described, the module must be packaged in a meaningful way. We are working to improve this, which can be found in "1.x to 2.0 migration document. The advantages of selecting a consistent local variable name are as follows:

• Maintain recommended naming rules for constructions, Mixin, and singletone.
• Provide an easily relevant name for the source module
• Selecting consistent local variable names makes it easier to reuse examples and tutorials of dojo.

The local variable name of the module can be referenced directly to the contained module. Sometimes a module identifier cannot be named by an ideal local variable. For example, if the name is a reserved Word Array in Javascript, we recommend that you add a suffix to arrayutil. Alternatively, if the module name contains a hyphen, such as "dojo/domo-construct", we recommend that you name it the correct JavaScript variable domconstruct. These local variables only reference the returned module dependencies locally, so they can be named at will, but the amd method can be effectively simplified according to the consistent format.
Conclusion

Naming a module in an appropriate way and ing it to the input parameters that call the function, and packaging it in a meaningful way can make the code more portable and easy to maintain and understand. To learn more about AMD technology, you can find help in the dojo workshop organized by sitepen. You can find support and help on the sitepen website to migrate some existing code to the new version of dojo, or rewrite or debug it.

Link to the original article: [Appendix