In js, import can import the export thing in another file. It should be noted that js seems to have the general things of a Spring container. As long as anything is imported once, the next time it is imported (for example, the same thing is imported in another js file), then these two things are the same . Therefore, based on this, we can achieve singleton mode very naturally in js. For example, if we need a data container DataPool, and we want this container to be globally unique and globally accessible, then we can directly export const dataPool = {} in a js file; then we import dataPool references in other files, In this way, the dataPool is a data container shared globally.
In other words, the content of the export will only be executed once.
In fact, when we import something from a js file, this js file has actually been executed once, and some of the exported things will be stored in a container, we can temporarily understand this container For something similar to Spring Container (it can also be understood as a container for storing objects if you don't know the spring container), when there is a place to use the stored thing, it is taken directly from the container. No matter how many times you take an object, you get the same object.
import should be used corresponding to export, and module.exports, exports should be used corresponding to require. Because the former is the es6 syntax and the latter is the syntax on the node, although it will be converted by babel, cross-use is prone to problems and even errors. For example, when export and exports are used together in a js file, an error will be reported.
From the point of view of actual operation, module.exports, exports, require, export, and import are exactly the same, and the entire js file will be executed again. However, module.exports, exports, and a js file in node can only export one object, and esport can export multiple. From this point of view, it is better to use es6.
But require also has advantages, because it can dynamically load a js file, dynamically load an object. For example, if (a> b) {person = require ('----')}; there are many things that can not be loaded in some configuration files, or may not be loaded temporarily, you can do so. This can obviously speed up the first presentation of large-scale react applications. For example, the following situation: In a project, you need to write corresponding components for each state in the United States to implement the special logic of each state. However, when you log in under the name of a state, the components of other states can Load, only load the current state. If you directly import all state components in the configuration file, obviously a lot of memory is wasted. At this point, we can first determine the state and then load the corresponding component. Another situation is that the page has not jumped to that page, for example, I have 10 steps in a workflow, corresponding to 10 pages. So, if we write all the components in the form of import from the beginning, the first rendering will be slower, which is also the biggest problem. Therefore, we can go to that page and require this component, waiting for the first time 10 Seconds, people prefer to wait 1 second each time, and this saves memory.
Another point is the problem of scope. Each imported js file is in its own scope. The variables imported without export and import cannot be used directly, but can be bound to some global objects. Properties, such as window. Of course, this is not recommended to avoid variable pollution.
