Shulou(Shulou.com)06/03 Report--

This article shows you how to better organize the four excellent practices of the JavaScript module, the content is concise and easy to understand, it will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Using the ES2015 module, you can divide your application code into reusable, encapsulated modules that focus on a single task.

This is good, but how do you construct the module? How many functions and classes should a module have?

1. Give priority to named export

When I started using the JavaScript module, I used the default syntax to export a single block defined by the module, whether it was a class or a function.

For example, this is a module program that exports module Greeter as the default value:

Over time, I noticed the difficulty of restructuring classes (or functions) that are exported by default. When renaming the original class, the class name in the consumer module does not change.

To make matters worse, the editor does not provide auto-completion advice on the name of the class to be imported.

My conclusion is that the default export does not bring obvious benefits. Then I turned to named export.

Let's name Greeter exit and look at the benefits:

With named exports, the editor can better rename: each time the original class name is changed, all consumer modules change the class name as well.

Autocomplete also recommends imported classes:

So, here's my advice:

"support for naming module exports to benefit from renaming refactoring and code completion."

two。 There is no heavy calculation during the import period.

The module-level scope defines functions, classes, objects, and variables. The module can export some of these components, like this.

Module-level scopes should not perform onerous calculations, such as parsing JSON, making HTTP requests, reading local storage, and so on.

For example, the following module configuration parses the configuration from the global variable bigJsonString:

This is a problem because the parsing of bigJsonString is done at the module level. Parsing of bigJsonString actually occurs when the configuration module is imported:

At a higher level, the role of module-level scope is to define module components, import dependencies, and export common components: this is the dependency resolution process. It should be separate from the runtime: parsing the JSON, making requests, handling events.

Let's ReFactor the configuration module to perform deferred parsing:

Because the data property is defined as a getter, the bigJsonString is parsed only when the consumer accesses the configuration.data.

Consumers have a better idea of when to do a big operation, and the user may decide to perform it when the browser is idle. Alternatively, the user may import the module, but for some reason does not use it.

This provides an opportunity for deeper performance optimization: reducing interaction time and greatly reducing the work of the main thread.

When importing, the module should not perform any heavy work. Instead, the consumer should decide when to perform run-time operations.

3. Use high cohesion modules as much as possible

Cohesion describes the degree to which the components within a module are together.

The functions, classes, or variables of highly cohesive modules are closely related, and they focus on a single task.

The formatDate module is highly cohesive because its functionality is closely related and focuses on date formatting:

FormatDate (), ensureDateInstance (), and MONTHS are closely related to each other. Deleting MONTHS or ensureDateInstance () destroys formatDate (): this is a sign of high cohesion.

4. Avoid longer relative paths

I find it difficult to understand that the path of a module contains one or more parent folders:

Having a parent selector.. / is usually not a problem, and having two or more is usually difficult to master.

This is why I recommend avoiding parent folders and using absolute paths:

Although it sometimes takes longer to write the absolute path, using the absolute path makes the location of the imported module clear.

To reduce lengthy absolute paths, a new root directory can be introduced. For example, this can be implemented using babel-plugin-module-resolver.

Use absolute paths instead of longer relative paths.

5. Conclusion

The JavaScript module is ideal for splitting your application logic into separate chunks.

By using a named export instead of the default export, it is easier to rename the refactoring and the editor to automate the help when importing named components.

The only purpose of using import {myFunc} from 'myModule' is to import myFunc components, that's all. The module-level scope of myModule should define only classes, functions, or variables that contain a small amount of content.

How many functions or classes should a component have, and how should these components relate to each component? Modules that support high cohesion: its components should be closely related and perform a common task.

Long relative paths containing many parent folders.. / are difficult to understand, so they are refactored to absolute paths.

The above content is how to better organize the four excellent practices of the JavaScript module. Have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.