Cómo entender la modularidad del front-end
Modularización del front-end
En los primeros días del desarrollo de JavaScript, se trataba de implementar una lógica de interacción de página simple en solo unas pocas palabras, ahora el rendimiento de la CPU y del navegador se ha mejorado enormemente; y muchos La lógica de la página se ha migrado al cliente (validación de formularios, etc.). Con el advenimiento de la era web2.0, la tecnología Ajax se ha utilizado ampliamente y las bibliotecas front-end como jQuery han surgido sin cesar. -El código final se ha expandido cada vez más
En este momento, JavaScript se utiliza como un lenguaje de programación incrustado. JavaScript no proporciona ninguna ayuda obvia para organizar el código. el concepto de clases, y mucho menos los módulos, las especificaciones de organización de código extremadamente simples de JavaScript no son suficientes para administrar una escala de código tan grande
Módulo
Dado que JavaScript no puede manejar un código de tan gran escala. , Podemos aprender de cómo otros lenguajes manejan la programación a gran escala. Hay un concepto importante en Java: el código relacionado lógicamente está organizado en el mismo paquete, y no hay necesidad de preocuparse. sobre conflictos de nombres. Entonces, ¿qué pasa si se usa externamente? Simplemente importe el paquete correspondiente directamente
import java.util.ArrayList;
Desafortunadamente, JavaScript no proporciona funciones similares debido a su posicionamiento durante el diseño. La función para aislar y organizar código JavaScript complejo se llama modularización.
Un módulo es un archivo que implementa una función específica. Con un módulo, podemos usar el código de otras personas de manera más conveniente y cargar cualquier módulo que queramos para cualquier función que queramos. El desarrollo del módulo debe seguir ciertas normas, y todos se arruinarán si hacen lo suyo.
El proceso de formación de normas es doloroso. Los pioneros del front-end comenzaron en la etapa de slash-. y quemar agricultura y beber sangre, y el desarrollo ha comenzado a tomar forma ahora. Entendamos brevemente esto. Un viaje extraordinario
Encapsulación de funciones
Cuando hablamos de funciones, mencionamos eso. Una función de una función es empaquetar un conjunto de declaraciones para implementar una lógica específica, y el alcance de JavaScript se basa en funciones, por lo que es natural usar funciones como el primer paso en la modularización. Escribir varias funciones relacionadas en un archivo es el. primer módulo
función fn1(){
declaración
}
función fn2(){
declaración
}
De esta manera, cuando sea necesario en el futuro, simplemente recórtelo en el archivo donde se encuentra la función y llame a la función.
Las desventajas de esto El enfoque es obvio: contamina las variables globales, no hay garantía de que los nombres de las variables no entren en conflicto con otros módulos y no hay relación entre los miembros del módulo.
Objetos
Para resolver los problemas anteriores, surgió el método de escritura de objetos, que puede encapsular todos los miembros del módulo en un objeto
var myModule = {
var1: 1,
var2: 2,
fn1: función(){
},
fn2: function(){
}
}
De esta manera, referenciamos el archivo correspondiente cuando queremos llamar al módulo, y luego
myModule .fn2();
Esto evita la contaminación variable, siempre que el nombre del módulo sea único y los miembros del mismo módulo también estén relacionados
Parece una buena solución, pero también hay fallas. Los miembros externos pueden modificar los miembros internos a voluntad
myModel.var1 = 100;
Esto causará problemas de seguridad inesperados
Ejecutar la función inmediatamente
Puedes ocultar detalles ejecutando la función inmediatamente
var myModule = (function(){
var var1 = 1 ;
var var2 = 2;
función fn1(){
}
función fn2(){
}
return {
fn1: fn1,
fn2: fn2
};
} )();
De esta manera, las variables y funciones que no hemos expuesto no se pueden modificar fuera del módulo
El enfoque anterior es la base de nuestra modularización. dos especificaciones principales de módulos JavaScript populares: CommonJS y AMD
p>CommonJS
Comencemos con CommonJS, porque no hay programación modular en la página web, solo la lógica JavaScript de la página es compleja , pero aún puede funcionar, pero debe haber módulos en el lado del servidor, por lo que aunque JavaScript se ha desarrollado en la web durante tantos años, la primera especificación modular popular fue aportada por las aplicaciones JavaScript del lado del servidor. presentado por NodeJS, que marcó la entrada oficial de la programación modular JavaScript en el escenario.
Definición de módulos
Según la especificación CommonJS, un único archivo es un módulo. Cada módulo tiene un alcance independiente, es decir, las variables definidas dentro del módulo no pueden ser leídas por otros módulos a menos que estén definidas como atributos del objeto global
Salida del módulo:
El módulo tiene solo una salida, el objeto module.exports. Necesitamos colocar el contenido que el módulo desea generar en este objeto.
Cargando el módulo:
Cargando el módulo utiliza. el método require. El método lee un archivo y lo ejecuta, devolviendo el objeto module.exports dentro del archivo