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 diseños jerárquicos y granulares, abstrayendo conceptualmente "núcleo", "herramientas" y "componentes". Cada pequeña función se coloca en un archivo y se debe hacer referencia a ella misma cuando sea necesario. Como se indica en la documentación de Yui, este diseño obviamente no es tan amigable para los principiantes como jquery, y no es tan estúpido como para implementar una función pequeña, se deben introducir tres o cuatro archivos js. 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 de carga dinámica.
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, el archivo cargado dinámicamente no es necesario. para iniciar una solicitud http real después de almacenarla en caché Solicitud, en segundo lugar, la carga dinámica puede realizar la carga bajo demanda y puede deduplicar y ordenar de acuerdo con las dependencias entre archivos js. La carga de archivos js con etiquetas escritas a mano requiere que los desarrolladores presten especial atención. clasificación, duplicación, etc. de archivos. En tercer lugar, la carga dinámica favorece la semántica del código de la página, lo que permite a los desarrolladores solo preocuparse por "lo que se necesita" sin preocuparse por "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 causará problemas al reutilizar el código. De manera similar, al depurar, los ingenieros deben abrir dos ventanas y 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, inmediatamente comprende que se trata de un bloque funcional independiente, que incluye una estructura HTML típica y una lógica de inicio js. Si desea reutilizarlo, simplemente puede copiar el bloque completo.
<!–Un fragmento de código html lógico–>
<script src="logicA.js" />
<guión>
$.onDomReady(función(){
___LogicA.start();
});
</script>
…
<!–B fragmento de código html lógico–>
<script src="logicB.js" />
<guión>
$.onDomReady(función(){
___LogicB.start();
});
</script>