I. Introducción
Este artículo presentará la exploración y la práctica unificadas de múltiples extremos de vivo mall en la dimensión de front-end en su conjunto.
Desde el valor de múltiples extremos, por qué necesitamos hacer una unificación de múltiples extremos, cómo satisfacer las necesidades de negocios de múltiples extremos, la práctica y la innovación, es conciso y sencillo explicar lo que hemos hecho en la unificación de múltiples extremos.
2. ¿Qué valor aporta la exploración de varios extremos al centro comercial vivo?
El valor multi-final puede reflejarse en dos aspectos: actualización de la arquitectura técnica y liberación de recursos humanos.
1. Actualización integral de la arquitectura técnica
Desde
A
Hemos logrado la unificación de soluciones de arquitectura técnica. A través de la unificación, el costo de desarrollo y el costo de mantenimiento se reducen considerablemente. Al mismo tiempo, tiene alta reutilización y alta eficiencia.
2. Liberar una gran cantidad de recursos humanos
La unificación del esquema de arquitectura técnica proporciona un fuerte soporte técnico y una garantía alcanzable para la expansión horizontal del negocio.
La siguiente figura es la proporción de la entrada de mano de obra para el desarrollo después de utilizar la nueva arquitectura técnica.
Como puede verse en la figura anterior, se han liberado considerables recursos de desarrollo mediante la actualización de la arquitectura técnica. Deje que los recursos de desarrollo publicados hagan cosas más valiosas.
3. ¿Por qué queremos hacer una unificación de varios extremos?
Puede que tenga preguntas, pero ¿qué es la unificación de varios extremos?
Aquí venderé un punto clave primero, no hablemos de unidad, hablemos más de eso. ¿Qué es multi-end? Creo que todos pueden hablar de eso.
Con respecto a la terminal múltiple, hice un dibujo de la siguiente manera:
Como puede ver en la figura anterior, sin conexión, pc, wap, APP, cuenta oficial de WeChat, subprograma de WeChat, etc., cada uno puede llamarse terminal. Conociendo el significado de multi-end, ahora miramos hacia atrás en la unificación de multi-end.
Una unificación completa de múltiples terminales debe incluir la unificación de los siguientes aspectos
- Unificación multi-end de gran front-end [front-end + cliente]
- Unificación de múltiples extremos del servidor
- Unificación de negocios multiterminal
Aquí, solo discutimos la unificación de múltiples extremos del front-end.
Desde el navegador de la PC, el navegador móvil, la incrustación de aplicaciones, varios programas pequeños, el servidor y el cliente. Una ecología próspera es como cien escuelas de pensamiento en contienda y cien flores en flor. Sin embargo, detrás de la prosperidad, los desafíos para los ingenieros de front-end aumentan día a día.
Cada vez emprendemos más terminales, y siguen apareciendo nuevos terminales, como pequeños programas y aplicaciones rápidas. Los ingenieros de front-end caen en la siguiente trampa de muñecas:
- El código existente y el código nuevo deben adaptarse a los nuevos escenarios de desarrollo final
- El código que se ha adaptado al nuevo escenario de desarrollo final se convierte en el código existente
- El código existente y el código nuevo deben adaptarse a los nuevos escenarios de desarrollo final
- ciclo...
Esperamos resolver este problema y lograr un conjunto de esquema de arquitectura técnica [código] que pueda cubrir el final actual y el final futuro.
En términos sencillos, esperamos lograr las capacidades que se muestran en la siguiente figura:
En este contexto de desarrollo de front-end, emerge unificado de múltiples terminales. Es una tendencia futura en la parte delantera, y también es una buena medicina para resolver la trampa de muñecas anterior.
Cuarto, cómo satisfacer la creciente demanda de negocios con múltiples terminales
Con el paso del tiempo, el negocio de las terminales pequeñas se ha ido volviendo cada vez más importante, especialmente el pequeño programa WeChat de vivo mall.
Los requisitos del lado comercial tienen dos puntos, como sigue:
El primer punto: hacer que las funciones principales del subprograma WeChat del centro comercial vivo existente sean coherentes con las funciones del centro comercial H5.
El segundo punto: la iteración posterior de la versión, el terminal pequeño y el terminal H5 están sincronizados.
La realidad es: el subprograma WeChat del centro comercial existente, su versión iterativa ya está detrás de la versión del centro comercial H5 .
Comparamos los videos del proceso de compra de las versiones nueva y antigua del Mini Programa para brindarles a todos una experiencia más intuitiva.
Mini programa Old Mall: Video >>
Nueva versión del applet del centro comercial: Vídeo >>
La diferencia entre los dos se puede ver en los dos videos anteriores, y el desafío al que nos enfrentamos es genial.
De acuerdo con los requisitos del lado comercial, lo que tenemos que hacer es resolver los dos puntos anteriores, sumar un punto, hay tres puntos en total, como se muestra a continuación:
El primer punto: en el menor tiempo posible, las funciones y procesos básicos del mall H5 se implementarán en el applet de WeChat.
El segundo punto: lograr una alta reutilización y eficiencia cuando se sincronizan las funciones de los siguientes miniprogramas y versiones H5.
- El tercer punto: considerar de antemano la implementación de otros escenarios comerciales en el futuro, y hacer un buen trabajo de escalabilidad y reutilización de múltiples terminales.
Impulsados por el negocio, llevamos a cabo investigaciones técnicas, verificación de demostración y verificación de mvp. Finalmente, bajo una consideración integral, se adoptó la arquitectura de múltiples terminales uni-app para resolver las dos dificultades anteriores.
Para mencionar aquí, un buen modelo impulsado por los negocios es aproximadamente como se muestra en la siguiente figura:
A través del negocio para promover la optimización y el cambio de tecnología, en el proceso de aplicación repetida, retroalimentación en tiempo real para la mejora y, finalmente, volver al negocio. En este proceso, la tecnología y los negocios han formado un ciclo cerrado benigno.
AHORA El resto es para practicar.
5. Qué prácticas e innovaciones hemos realizado
Un famoso dicho dice así: la práctica es el único criterio para probar la verdad . Es cierto que detrás de los ganadores hay un trabajo duro y una perseverancia que no se ve.
1. Practica
En el curso de la práctica, hay muchos factores a considerar, que se enumeran a continuación:
- Cómo convertir el código nativo de pequeños programas existentes en escritura de proyectos de múltiples terminales para garantizar que el código convertido sea legible y controlable.
- Parte de la lógica funcional del subprograma existente debe conservarse por completo, incluso la api nativa y la lógica del subprograma, ¿cómo pueden coexistir con proyectos de múltiples terminales?
- Cómo reutilizar la lógica del código H5 en la mayor medida posible en proyectos de múltiples terminales.
- Cómo adaptar elegantemente los diversos componentes, patrones de diseño, ingeniería y métodos de herramientas de H5 a proyectos de múltiples terminales.
- y muchos más...
Entonces, ¿cómo lidiamos con estos factores?
Podemos utilizar una imagen para resumir como un todo, como se muestra a continuación:
Así es como nos ocupamos de estos factores.
2. Conversión de código
¿Cómo convertir el código nativo de los mini programas existentes en la escritura de proyectos de múltiples terminales para garantizar que el código convertido sea legible y controlable?
Usamos el convertidor de código abierto miniprograma a uniapp para realizar la conversión y luego resolvemos manualmente el problema de desajuste durante el proceso de conversión. La solución es tan simple y sin pretensiones. Quizás todos piensen que la solución es simple. Pero detrás de elegir esta solución, hicimos una evaluación detallada, incluido un intercambio de WeChat con el autor del convertidor de código abierto. En el proceso de comunicación con el autor conocimos el pasado, presente y futuro del convertidor, dadas las circunstancias, esta fue una solución adecuada y correcta.
3. Coexistencia de códigos
Parte de la lógica funcional del applet existente debe conservarse intacta, incluso la api nativa y la lógica del applet, ¿cómo pueden coexistir con proyectos de múltiples terminales?
Logramos un aislamiento natural a través de una división razonable del catálogo del proyecto, como se muestra en la siguiente figura:
Colocamos algunos códigos que aún no son compatibles con múltiples terminales en el directorio de plataformas. Al mismo tiempo, usaremos la compilación condicional para aislar plataformas que no se pueden convertir a terminales múltiples. Como se muestra abajo:
4. Multiplexación y adaptación de h5
Reutilizar se trata de una palabra perezosa. Si se puede reutilizar directamente, reutilícela de manera decisiva. No haga ajustes secundarios para asegurarse de que sea muy consistente con H5.
La adaptación se trata de adaptarnos a los cambios. No necesitamos cambiar el código H5. Solo necesitamos hacer una capa de adaptación para ellos, como adaptar el enrutamiento H5, algunos componentes incompatibles e incluso adaptarnos a la ventana. La ubicacion esta bien.
A partir de las soluciones introducidas anteriormente, podemos darnos cuenta de que el secreto central para lidiar con estos factores son las siguientes dos oraciones:
La primera frase: ajustar las medidas a las condiciones locales y encontrar un equilibrio.
Segunda frase: mejorar la reutilización y reducir los cambios.
5. Innovación
Hay un dicho que dice así: La grandeza se concibe en lo ordinario . Poniéndolo aquí, digámoslo de otra manera, es decir , la innovación genera en la práctica .
En el curso de la práctica, hemos resuelto muchos problemas. En el proceso de resolver el problema, hicimos algunas innovaciones felices.
- innovación vuex
Esta innovación tiene su origen en un problema, cuyo trasfondo es el siguiente:
La página de detalles del producto del centro comercial H5 usa vuex para administrar los datos. Cuando vuex se mueve a la página de detalles del producto del mini programa, se encuentra un fenómeno, como se muestra en la siguiente animación:
De la animación anterior, encontramos que cuando usamos vuex, hacemos clic en el producto B desde la página de detalles del producto A para ingresar a la página de detalles del producto de B. En este momento, hacemos clic en la esquina superior izquierda para volver a la página de detalles del producto de A, y encontraremos que la página de detalles del producto ha cambiado al producto B en este momento, es decir, los datos del producto A se han ido.
Este es un problema muy grande. Después de la investigación, las razones son las siguientes:
El espacio de nombres predeterminado de vuex es uno y el espacio de nombres no se puede agregar automáticamente. Cuando se utiliza vuex para la gestión de datos en la página del subprograma, debido al mecanismo de datos de la página del subprograma, cuando hace clic para volver, los datos de la página utilizan los mismos datos de vuex, lo que conduce al fenómeno anterior.
Aquí, alguien podría decir que en el ciclo de vida de onShow, actualizar los datos resolverá el problema. De hecho, no lo es. En este escenario, no es razonable actualizar los datos.
Entonces, ¿cómo solucionarlo?
Sabemos que después de usar vuex, los datos de la página del applet tendrán problemas de visualización después de ingresar a la misma página varias veces. Posteriormente, el grupo discutido, luego de un pesaje exhaustivo, decidió continuar usando vuex y resolver este problema agregando una capa de adaptación a vuex.
Posteriormente, el grupo tuvo una discusión, y luego de un balance integral, se decidió continuar usando vuex. Este problema se resuelve agregando una capa de adaptación a vuex.
En primer lugar, veamos qué sucede después de agregar una capa de adaptación a vuex y realizar las operaciones anteriores.
Como se muestra en la siguiente animación:
De la animación anterior, podemos encontrar que después de agregar una capa de adaptación a vuex. Resolvió con éxito el problema de visualización de los datos de la página del programa pequeño después de usar vuex, después de ingresar a la misma página varias veces y hacer clic en Atrás.
¿Cómo solucionamos este problema?
Solución principal: se puede lograr una solución de administración de flujo de datos más inteligente al permitir que vuex admita la expansión automática y la cancelación automática del espacio de nombres .
El diagrama de la arquitectura central es el siguiente
Al generar automáticamente el espacio de nombres en la tienda, se garantiza que los datos de cada página se conserven después de que se ingrese la misma página varias veces. Cuando la página regresa, la asociación de espacios de nombres de los componentes principal y secundario se completa mediante la recopilación dinámica del espacio de nombres del componente principal.
A través de las soluciones técnicas anteriores, hemos resuelto los problemas que existían cuando se usaba vuex en programas pequeños. Aquí, se ha proporcionado el esquema de la arquitectura central y la implementación específica no se describirá en detalle.
6. Desacoplamiento de la innovación
Esta innovación tiene su origen en un problema, cuyo trasfondo es el siguiente:
Ahora tenemos páginas de detalles de productos comunes, de picos y de grupo, y habrá otras páginas de detalles de productos más adelante, entonces, ¿cómo reutilizamos los componentes comerciales en estas páginas de detalles?
Frente a los problemas anteriores, todos tendrán los siguientes pensamientos:
-
Diferentes páginas, el procesamiento de datos en componentes comerciales es diferente
-
Diferentes páginas, los puntos enterrados en los componentes comerciales son diferentes
- Diferentes páginas, puede haber solicitudes de interfaz específicas en componentes comerciales
Los pensamientos anteriores, todos deberían haberlo visto.La reutilización de los componentes comerciales en sí es algo muy difícil, y es aún más difícil si desea desacoplarlos por completo.
Entonces, ¿cómo nos desacoplamos tanto como sea posible?
Hicimos lo siguiente:
- Asegurar la unificación de puntos enterrados en la parte superior y lograr la unificación de puntos enterrados diseñando los puntos enterrados a nivel de componente.
- A nivel de componente, se realizan juicios condicionales para interfaces específicas.
- Los datos del componente empresarial se descomponen en datos de origen y datos derivados. Los datos de origen son coherentes a nivel de vuex y los datos derivados se adaptan en consecuencia en el componente empresarial de acuerdo con la situación real.
- Renueve vuex para desacoplar completamente la comunicación entre los componentes comerciales y las páginas, y los componentes comerciales ya no necesitarán conocer el espacio de nombres vuex de la página.
Los estudiantes que han desarrollado el proyecto del centro comercial deben saber que la lógica de la capa de bomba seleccionada es muy complicada. Aquí, tomaremos el componente comercial de la capa de bomba seleccionada como ejemplo para ilustrar cómo hacemos la reutilización de componentes comerciales.
La siguiente es la composición de los componentes de la capa de bomba seleccionados que se han reutilizado:
├── components
│ ├── sku-number
│ ├── sku-product
│ ├── sku-service
│ ├── sku-spec
│ └── ...
├── index.js
├── index.scss
├── index.vue
├── mutation-types.js
└── track.jsDividimos los datos de los componentes de la capa de bombas seleccionados en datos de origen y datos derivados. Los datos de origen se unifican en el nivel vuex, como se muestra en la siguiente figura:
Escribimos un vuex para cada página de detalles y, al mismo tiempo, extraemos la misma parte en detalle común. Después de eso, procesamos en vuex para asegurarnos de que los datos de origen proporcionados por diferentes páginas sean los mismos. Estos datos de origen deben pasarse a los componentes comerciales.
Como se muestra en el siguiente código:
// 这是已选弹层业务组件
// 通过 @vivo/smartx 解耦组件和页面的通信
import { mapState, mapGetters, mapMutations, mapActions } from '@vivo/smartx'
// 获取源数据
computed: {
...mapState([
'spuInfo',
'skuInfo'
]),
...mapGetters([
'price',
'pageType'
]),
}
methods: {
fn() {
// 策略模式
}
}A través del procesamiento anterior, los componentes comerciales similares se pueden desacoplar bien de diferentes páginas, mejorando así la reutilización, el mantenimiento y la escalabilidad del código.
La idea de desacoplar componentes empresariales radica en:
No es necesario separar deliberadamente los datos y la vista por completo. A través de los datos de origen y los datos derivados, los datos modificados y los que no cambian se equilibran, y luego, a través de @ vivo / smartx de desarrollo propio, el cambio se convertirá en una isla, y el cambio se convertirá en una isla. Isla aislada.
Toda innovación es una prueba, siempre te da dificultades sin darte cuenta y luego te obliga a abrirte paso, creando así cosas mejores, repitiendo el ciclo.
Finalmente, se ha lanzado el mini programa WeChat multi-terminal del centro comercial oficial de vivo. Puede hacer clic en la tienda oficial de vivo para experimentarlo.
Seis, resumen
En este artículo, revisamos juntos el camino unificado de múltiples extremos de los applets de WeChat en el centro comercial in vivo. Desde las necesidades comerciales, el valor de la existencia, hasta la práctica técnica y la innovación, esperamos utilizar la tecnología para hacer que el camino de múltiples extremos sea más suave.
Equipo front-end del centro comercial del sitio web oficial de Vivo