¿La página html de una aplicación de una sola página debe llamarse index.html?
Marco de desarrollo
ExtJS es un representante típico del marco de aplicación de una sola página de primera generación. Encapsula varios componentes de la interfaz de usuario. Los usuarios utilizan principalmente JavaScript para completar toda la parte del front-end. , incluso incluyendo el diseño. Con el aumento gradual de la funcionalidad, el tamaño de ExtJS ha aumentado gradualmente. Incluso para el desarrollo de sistemas internos, a veces parece engorroso, y mucho menos desarrollar sistemas como el anterior que se ejecutan en Internet.
Dado que jQuery opera en DOM, su sistema de complementos es relativamente flexible, por lo que es más adecuado para desarrollar sistemas de una sola página que se ejecutan en la red pública que sistemas como ExtJS y la solución completa. Será relativamente simple y ligero.
Pero debido a que jQuery está orientado principalmente a operaciones de nivel superior, carece de restricciones en la organización del código. Cómo controlar la cohesión de cada módulo y generar adecuadamente la transmisión y el intercambio de datos entre módulos cuando el código se expande rápidamente se ha convertido en un asunto muy desafiante.
Para resolver los problemas de lógica del código cuando aumenta la escala de las aplicaciones de una sola página, han surgido algunos marcos MV*. Su idea básica es crear capas de módulos y mecanismos de comunicación en la capa JS. Algunos son MVC, otros son MVP y algunos son MVVM. Casi todos los marcos tienen variaciones de estos patrones para adaptarse a las características del desarrollo front-end.
Estos frameworks incluyen Backbone, Knockout, AngularJS, Avalon, etc.
Componentización
Estos marcos que están en capas en el front-end promueven la componenteización del código. La llamada componenteización, en los productos web tradicionales, se refiere más a los componentes de la interfaz de usuario. El componente es un concepto amplio. La proporción de componentes de interfaz de usuario en los productos web tradicionales es muy alta. La razón es que a medida que aumenta la proporción de código de cliente, una parte considerable de la lógica empresarial también es front-end.
Una de las ventajas de la estratificación es que las responsabilidades de cada capa son más especializadas, lo que permite la cobertura de pruebas unitarias para garantizar la calidad. El mayor problema con las pruebas de la capa de UI tradicional es que la capa de UI está mezclada con lógica; por ejemplo, el DOM a menudo cambia en las devoluciones de llamada de solicitudes remotas. Con la introducción de las capas, todas estas cosas se pueden probar individualmente y luego se pueden utilizar pruebas de escenarios para garantizar el flujo general.
Aislamiento de código
En comparación con el desarrollo de sitios web tradicionales basados en páginas, hay varios puntos a los que vale la pena prestar especial atención al implementar aplicaciones de una sola página.
A juzgar por las características de una aplicación de una sola página, se basa más en JavaScript que un sitio web basado en páginas y, debido a la naturaleza de una sola página de la página, los códigos JavaScript para varias subfunciones se concentran en el mismo alcance, por lo que el aislamiento y la modularización del código se vuelven muy importantes.
En aplicaciones de una sola página, el uso de plantillas de página es muy común. Muchos marcos tienen plantillas específicas integradas, mientras que algunos marcos requieren la introducción de plantillas de terceros. Estas plantillas son fragmentos de interfaz, que podemos comparar con los módulos de JavaScript, que son otro tipo de componente.
Las plantillas también deben aislarse. ¿Qué problemas pueden surgir si no se aíslan las plantillas? Los conflictos entre plantillas existen principalmente en el atributo de identificación; si una plantilla contiene una identificación fija, cuando se procesa en lotes, aparecerán múltiples elementos con la misma identificación en el alcance de la misma página, lo que provocará consecuencias impredecibles.
Por lo tanto, debemos evitar el uso de identificadores en las plantillas y si necesitamos acceder al DOM, debemos hacerlo a través de otros selectores. Si una aplicación de una sola página tiene muchos componentes, lo más probable es que los identificadores de elementos no se utilicen en toda la aplicación.
Estrategias de carga y fusión de código
En un sistema de una sola página, la tolerancia de las personas al tiempo de carga es diferente a la de una página web. Si están dispuestos a esperar 3 segundos para que se cargue una página de compras, entonces es probable que estén dispuestos a esperar entre 5 y 10 segundos para que se cargue una aplicación de una sola página por primera vez, pero después de eso, se deben utilizar varias funciones. Sin problemas, todas las páginas de subfunciones deben cambiarse en 1 o 2 segundos tanto como sea posible. Todas las páginas de subfunciones deben cambiarse correctamente en 1 o 2 segundos; de lo contrario, el usuario sentirá que el sistema está funcionando lentamente.
Según estas características, podemos colocar más funciones de **** públicas en la primera carga para reducir la carga de cada carga. Algunos sitios web incluso colocan todas las interfaces y la lógica. Todas se cargan en la página de inicio. Cuando se cambia la interfaz empresarial, solo se generan solicitudes de datos, por lo que la velocidad de respuesta es muy rápida. Por ejemplo, la consola de Qingyun hace esto.
Por lo general, en aplicaciones de una sola página, no es necesario cargar js después de html para evitar que la carga de archivos bloquee la representación como en los productos basados en web, porque su interfaz se genera básicamente de forma dinámica.
Al cambiar de función, además de generar solicitudes de datos, la interfaz también debe renderizarse. Este componente de interfaz recién renderizado suele ser una plantilla de interfaz. Solo hay dos fuentes, una es una solicitud inmediata, como solicitar datos a través de AJAX, y la otra está integrada en ciertas ubicaciones de la interfaz principal, como etiquetas de script o áreas de texto invisibles. La ventaja de esta última es que es rápida. al cambiar de función, pero aumenta la carga en la página principal.
En los sitios web tradicionales basados en páginas, las páginas están aisladas entre sí, por lo que si hay código reutilizable entre las páginas, generalmente se extraerá en archivos separados y es posible que sea necesario fusionar cada página. Para una aplicación de una sola página, si la cantidad total de código no es grande, se puede empaquetar como un todo y cargar en la página de inicio. Si alcanza una cierta escala, se puede cargar en tiempo de ejecución. La granularidad de carga puede ser mayor. , y no habrá duplicaciones entre diferentes bloques.
Enrutamiento y Gestión de Estado
¿Cuál es el propósito de gestionar el enrutamiento? Es para reducir el costo de navegación del usuario. Digamos que tenemos una función que requiere varios clics en un menú de navegación antes de que se muestre. ¿Qué debe hacer un usuario si desea compartir la dirección de la función con otros?
Los productos tradicionales basados en páginas no tienen este problema porque todo gira en torno a la página y, a veces, el enrutamiento del lado del servidor se encarga de todo. Pero en una aplicación de una sola página, esto se convierte en un problema porque solo tenemos una página y los distintos bloques funcionales en la interfaz se generan dinámicamente. Por lo tanto debemos gestionar el enrutamiento para lograr estas funciones.
El método específico es dividir las funciones del producto en varios estados, cada estado se asigna a la ruta correspondiente y luego analiza dinámicamente la ruta a través de pushState y otros mecanismos para que coincida con la interfaz funcional.
Con el enrutamiento, nuestro producto de una sola página puede avanzar y retroceder como si estuviera entre páginas.
De hecho, fuera de los productos web, hace tiempo que existen soluciones técnicas para gestionar el enrutamiento. Por ejemplo, en Adobe Flex, el TabNavigator e incluso el estado seleccionado del cuadro desplegable corresponden a la URL, porque también es un modelo de producto de "página" única y necesita abordar los mismos problemas.
Almacenamiento en caché y local
El almacenamiento en caché es una parte importante del mecanismo de aplicación de una sola página.
Dado que la parte frontal de dicho sistema está formada casi en su totalidad por archivos estáticos, puede tener la oportunidad de aprovechar el mecanismo de almacenamiento en caché del navegador. Por ejemplo, las plantillas de interfaz cargadas dinámicamente pueden adoptar por completo algún almacenamiento en caché personalizado. Mecanismos, obteniendo directamente la versión en caché en solicitudes que no sean las primeras para acelerar la carga.
Incluso hay programas que almacenan en caché el código JavaScript mientras lo cargan dinámicamente. Por ejemplo, basket.js de Addy Osmani aprovecha el almacenamiento local HTML5 para almacenar en caché archivos js y css.
En productos de una sola página, el código comercial generalmente necesita usar almacenamiento local para almacenar algunos datos temporales. Puede usar localStorage o localStorageDB para simplificar su código comercial.
Comunicación del lado del servidor
Los productos web tradicionales suelen utilizar JSONP o AJAX para comunicarse con el servidor, pero en aplicaciones web de una sola página, una gran parte de ellos utilizan WebSocket y otras aplicaciones reales. -métodos de comunicación en el tiempo.
WebSocket tiene grandes ventajas sobre los mecanismos de comunicación tradicionales basados en HTTP. Permite que el lado del servidor utilice convenientemente la inserción inversa, mientras que el front-end solo responde a eventos que realmente producen datos comerciales, lo que reduce la necesidad de realizar repetidos sondeos AJAX inútiles.
Dado que WebSocket solo admite navegadores más avanzados, existen algunas bibliotecas que brindan soluciones de compatibilidad en diferentes navegadores. Por ejemplo, en navegadores que no admiten WebSocket, puede cambiar a AJAX o JSONP, etc. Completamente transparente y compatible con el código empresarial.
Administración de memoria
Las páginas web tradicionales generalmente no necesitan considerar la administración de memoria, porque el tiempo de permanencia del usuario es relativamente pequeño e incluso si ocurre una pérdida de memoria, puede actualizarse rápidamente. Las páginas y otras operaciones se eliminan, pero las aplicaciones de una sola página son diferentes. Es probable que los usuarios las abran todo el día, por lo que debemos manejar las operaciones DOM, las conexiones de red, etc. y las conexiones de red de manera integrada. Hay que tener mucho cuidado con estas piezas.
Planificación de estilo
La planificación de estilo implica principalmente los siguientes aspectos:
Separación de estilos de línea base
Esto implica principalmente la reutilización de estilos del navegador. , configuración de fuente global, convenciones básicas de diseño y soporte responsivo.
Separación de estilos de componentes
Aquí hay dos niveles de planificación. El primero es el estilo de varios componentes de la interfaz y sus subelementos, y el segundo es el estilo de algunos modificadores. . Los estilos de los componentes deben minimizar la interdependencia y permitir la redundancia en el estilo de cada componente.
Gestión del orden de apilamiento
Las páginas web tradicionales se caracterizan por tener más elementos pero menos capas, mientras que las aplicaciones de una sola página son diferentes.