Creo que cada ingeniero de front-end tiene su marco de JavaScript favorito, ya sea por emoción o creencia. El marco de JavaScript no solo brinda un desarrollo conveniente, sino también una belleza lógica pura, ya sea la elegante simplicidad de jquery o la magia de Yui. sandbox, todos nos dan una imaginación infinita. Sin embargo, es probable que el marco js no pueda lograr la perfección total. Por ejemplo, las concesiones de jquery en OO y los sacrificios de yui en el rendimiento transmiten una especie de belleza imperfecta y un realismo ideal a las personas. Hoy, echemos un vistazo a estos sacrificios y concesiones hechos por yui3 en el diseño del marco, para que podamos tener una comprensión más profunda de la imagen completa de yui3 y maximizar sus ventajas.
1. Un paso o granulación de semillas
La llamada siembra de un solo paso significa que solo necesita introducir una etiqueta de secuencia de comandos de un archivo semilla en la página, como prototipo y jquery, y simplemente introducir un prototipo.js o jquery.js, que encapsularán las operaciones DOM. eventos, etc. en un archivo e intente mantenerlo lo más pequeño posible. Los beneficios de hacerlo son obvios. Usar el marco es muy simple. Sin embargo, Yui ha dividido estas funciones en niveles y diseños granulares, abstrayendo conceptualmente "núcleo", "herramientas" y "componentes". Cada función pequeña se coloca en un archivo cuando es necesario. de las demostraciones proporcionadas en la documentación de Yui adoptan este método. Este diseño obviamente no es tan amigable para los principiantes como jquery, y no es tan estúpido para implementar una pequeña función, incluso es necesario introducir tres o cuatro js. archivo. Hay dos razones para que Yui haga esto. En primer lugar, Yui es demasiado grande y es un poco poco confiable colocar todas las funciones en un solo archivo. En segundo lugar, allana el camino para su diseño de marco cargado dinámicamente.
2. Introducción manual o carga dinámica
El método tradicional para escribir js en una página es escribir directamente el archivo js en la página como la ruta de la etiqueta del script. También puede introducir la página de esta manera usando yui, pero yui recomienda usar el cargador para la carga dinámica. El origen de los scripts cargados dinámicamente es muy complicado. En la actualidad, hay tres razones principales. En primer lugar, las etiquetas js escritas a mano en la página ocuparán una solicitud http de todos modos. Incluso si la solicitud es 304, no es necesario iniciar una. Solicitud http real después de que el archivo cargado dinámicamente se almacene en caché Solicitud. En segundo lugar, la carga dinámica puede realizar la carga bajo demanda y puede basarse en archivos js. La deduplicación y clasificación de interdependencias, la carga de archivos js con etiquetas escritas a mano requiere que los desarrolladores presten especial atención a la clasificación, duplicación, etc. de los archivos. En tercer lugar, la carga dinámica favorece la semántica del código de la página, lo que hace que los desarrolladores solo se preocupen por "Qué". "lo que necesitas", en lugar de "cómo conseguirlo". Cuando los proyectos se vuelvan más inflados y los costos de mantenimiento sean cada vez más altos, estas técnicas pequeñas y medianas serán de gran beneficio.
3. Entrada única o zona de pruebas para inicio lógico
Cuando iniciamos una lógica js en una página, generalmente la colocamos en un método como onDomReady. ¿Qué pasa si hay varias lógicas en la página? Por ejemplo, a implementa la lógica A y el código de la página es así
<script src="logicA.js" />
<guión>
$.onDomReady(función(){
___LogicA.start();
});
</script>
Este código generalmente se escribe al final de la página. El código html que acompaña a esta lógica está enterrado en algún lugar de la página. En este momento, b necesita agregar la lógica B a la página. final y luego cámbielo para que se vea así:
<script src="logicA.js" />
<script src="logicB.js" />
<guión>
$.onDomReady(función(){
___LogicA.start();
___LogicB.start();
});
</script>
De manera similar, el código html que acompaña a la lógica B también está enterrado en algún lugar de la página. Parece que la lógica js y el código html que la acompaña están tan separados que cuando se trata de eliminar la función, el html a menudo se elimina pero el js se olvida. , o eliminar js y olvidarse de eliminar html también será un problema al reutilizar el código. De manera similar, al depurar, los ingenieros también tienen que abrir dos ventanas para centrarse en js y html respectivamente, incluso si las dos piezas de código están en el mismo archivo. En este caso, es mejor escribir el código así:
Este método de codificación es exactamente lo que defiende Yui, que es el llamado sandbox. Cada lógica está contenida en un sandbox y cada una hace lo suyo sin interferir entre sí. Cuando un tercero explora el código, comprende inmediatamente que se trata de un bloque funcional independiente, que incluye la estructura HTML típica y la lógica de inicio js. Si desea reutilizarlo, simplemente puede copiar el bloque completo.
<!—Un segmento de código html lógico—>
<script src="logicA.js" />
<guión>
$.onDomReady(función(){
___LogicA.start();
});
</script>
& infierno;
<!—B segmento de código html lógico—>
<script src="logicB.js" />
<guión>
$.onDomReady(función(){
___LogicB.start();
});
</script>