Mise à niveau de l'architecture frontale du centre commercial Vivo - Exploration, pratique et perspectives unifiées multi-extrémités

Introduction

Cet article présentera l'exploration unifiée multi-extrémité et la pratique du centre commercial vivo dans la dimension frontale dans son ensemble.

De la valeur multi-extrémité, pourquoi nous devons faire unification multi-extrémité, comment répondre aux besoins, pratique et innovation de l'entreprise multi-extrémité, il est concis et simple d'expliquer ce que nous avons fait dans l'unification multi-extrémité.

2. Quelle valeur l'exploration multi-extrémités apporte-t-elle au centre commercial vivo?

La valeur multi-end peut se refléter dans deux aspects: la mise à niveau de l'architecture technique et la libération des ressources humaines.

1. Mise à niveau complète de l'architecture technique

De

À

Nous avons réalisé l'unification des solutions d'architecture technique. Grâce à l'unification, les coûts de développement et de maintenance sont considérablement réduits. En même temps, il a une réutilisation élevée et une efficacité élevée.

2. Libérer beaucoup de ressources humaines

L'unification des solutions d'architecture technique fournit un support technique solide et une garantie réalisable pour l'expansion horizontale de l'entreprise.

La figure ci-dessous est le rapport entre la main-d’œuvre en développement et l’utilisation de la nouvelle architecture technique.

Comme le montre la figure ci-dessus, des ressources de développement considérables ont été libérées grâce à la mise à niveau de l'architecture technique. Laissez les ressources de développement publiées faire des choses plus précieuses.

3. Pourquoi voulons-nous faire une unification multi-extrémités

Vous avez peut-être des questions, mais qu'est-ce que l'unification multi-extrémités?

Ici, je vais d'abord vendre un point clé, ne parlons pas d'unité, parlons-en plus. Qu'est-ce que le multi-end? Je pense que tout le monde peut en parler.

En ce qui concerne le multi-terminal, j'ai dessiné une image comme suit:

Comme vous pouvez le voir sur la figure ci-dessus, hors ligne, pc, wap, APP, compte officiel WeChat, applet WeChat, etc., chacun peut être appelé un terminal. Connaissant la signification de multi-end, nous revenons maintenant à l'unification multi-end.

Une unification multi-terminal complète devrait inclure l'unification des aspects suivants

• Unification multi-end du grand front-end [front-end + client]
• Unification multi-extrémités du serveur
• Unification d'entreprises multi-terminaux

Ici, nous ne discutons que de l'unification multi-extrémité du front-end.

Du navigateur PC au navigateur mobile, en passant par l'intégration de l'APP, aux divers petits programmes, au serveur et au client. Une écologie prospère est comme une centaine d'écoles de pensée qui se disputent, et cent fleurs s'épanouissent. Cependant, derrière la prospérité, les défis pour les ingénieurs frontaux augmentent de jour en jour.

Nous entreprenons de plus en plus de terminaux, et de nouveaux terminaux continuent d'apparaître, comme les petits programmes et les applications rapides. Les ingénieurs frontaux tombent dans le piège des poupées suivant:

1. Le code existant et le nouveau code doivent être adaptés aux nouveaux scénarios de développement final
2. Le code qui a été adapté au nouveau scénario de développement final devient le code existant
3. Le code existant et le nouveau code doivent être adaptés aux nouveaux scénarios de développement final
4. cycle...

Nous espérons résoudre ce problème, et espérons parvenir à un ensemble de schéma d'architecture technique [code] qui peut couvrir la fin actuelle et la fin future.

En termes simples, nous espérons atteindre les capacités indiquées dans la figure suivante:

Dans ce contexte de développement front-end, le multi-end unifié émerge. C'est une tendance future dans le front-end, et c'est aussi un bon médicament pour résoudre le piège de poupée ci-dessus.

Quatrièmement, comment répondre à la demande croissante des entreprises multi-terminaux

Avec le temps, l'activité des petits terminaux est devenue progressivement plus importante, en particulier le petit programme WeChat du centre commercial vivo.

Les exigences du côté commercial comportent deux points, comme suit:

Le premier point: rendre les fonctions de base de l'applet WeChat du centre commercial vivo existant cohérentes avec les fonctions du centre commercial H5.

Le deuxième point: l' itération ultérieure de la version, le petit terminal et le terminal H5 sont synchronisés.

La réalité est la suivante: l' applet WeChat existant du centre commercial, son itération de version est déjà derrière la version du centre commercial H5 .

Nous comparons les vidéos du processus d'achat des nouvelles et anciennes versions du Mini Programme pour offrir à chacun une expérience plus intuitive.

Old Mall Mini Program: Vidéo >>

Nouveau programme Mini Mall: Vidéo >>

La différence entre les deux peut être vue à partir des deux vidéos ci-dessus, et le défi auquel nous sommes confrontés est grand.

Selon les exigences du côté commercial, ce que nous devons faire est de résoudre les deux points ci-dessus, ajoutez un point, il y a trois points au total, comme indiqué ci-dessous:

• Le premier point: dans les plus brefs délais, les fonctions et processus de base du centre commercial H5 seront implémentés sur l'applet WeChat

• Le deuxième point: obtenir une réutilisation et une efficacité élevées lorsque les fonctions des versions de mini-programme et H5 suivantes sont synchronisées.

• Le troisième point: envisager à l'avance la mise en œuvre d'autres scénarios commerciaux dans le futur, et faire un bon travail d'évolutivité et de réutilisation multi-terminaux.

Poussés par les affaires, nous avons mené des recherches techniques, une vérification de démonstration et une vérification mvp. Enfin, après un examen approfondi, l'architecture multi-terminal uni-app a été adoptée pour résoudre les deux difficultés ci-dessus.

Pour mentionner ici, un bon modèle axé sur les affaires est à peu près comme le montre la figure suivante:

Grâce à l'entreprise pour promouvoir l'optimisation et le changement de technologie, dans le processus d'application répétée, des commentaires en temps réel pour l'amélioration, et enfin le retour à l'entreprise. Dans ce processus, la technologie et les entreprises ont formé une boucle fermée bénigne.

MAINTENANT, le reste est de pratiquer.

5. Quelles pratiques et innovations avons-nous réalisées

Un dicton célèbre dit ceci: la pratique est le seul critère pour tester la vérité . Il est vrai que derrière les gagnants, il y a un travail acharné et une persévérance que vous ne pouvez pas voir.

1. Pratique

Au cours de la pratique, de nombreux facteurs doivent être pris en compte, comme indiqué ci-dessous:

1. Comment convertir le code natif de petits programmes existants en écriture de projet multi-terminal pour s'assurer que le code converti est lisible et contrôlable.
2. Une partie de la logique fonctionnelle de l'applet existante doit être entièrement préservée, même l'API native et la logique de l'applet, comment peuvent-elles coexister avec des projets multi-terminaux?
3. Comment réutiliser au maximum la logique du code H5 dans les projets multi-terminaux.
4. Comment adapter avec élégance les différents composants, modèles de conception, ingénierie et méthodes d'outils de H5 à des projets multi-terminaux.
5. et beaucoup plus...

Alors, comment gérer ces facteurs?

Nous pouvons utiliser une image pour résumer dans son ensemble, comme indiqué ci-dessous:

Voici comment nous gérons ces facteurs.

2. Conversion de code

Comment convertir le code natif de mini programmes existants en écriture de projet multi-terminal pour s'assurer que le code converti est lisible et contrôlable?

Nous utilisons le convertisseur open source miniprogram-to-uniapp pour effectuer la conversion, puis résolvons manuellement le problème de non-correspondance pendant le processus de conversion. La solution est si simple et sans prétention. Peut-être que tout le monde pense que la solution est simple. Mais derrière le choix de cette solution, nous avons fait une évaluation détaillée, y compris un échange WeChat avec l'auteur du convertisseur open source. Dans le processus de communication avec l'auteur, nous connaissions le passé, le présent et le futur du convertisseur et, dans les circonstances, c'était une solution appropriée et correcte.

3. Coexistence du code

Une partie de la logique fonctionnelle de l'applet existante doit être préservée intacte, même l'API native et la logique de l'applet, comment peuvent-elles coexister avec des projets multi-terminaux?

Nous obtenons une isolation naturelle grâce à une division raisonnable du catalogue du projet, comme le montre la figure suivante:

Nous mettons certains codes qui ne sont pas encore compatibles avec plusieurs terminaux dans le répertoire des plates-formes. Dans le même temps, nous utiliserons la compilation conditionnelle pour isoler les plates-formes qui ne peuvent pas être converties en multi-terminaux. Comme indiqué ci-dessous:

4. Multiplexage et adaptation de h5

La réutilisation concerne un mot paresseux. S'il peut être réutilisé directement, réutilisez-le de manière décisive. N'effectuez pas d'ajustements secondaires pour vous assurer qu'il est parfaitement cohérent avec H5.

L'adaptation consiste à s'adapter aux changements. Nous n'avons pas besoin de changer le code H5. Nous avons seulement besoin de faire une couche d'adaptation pour eux, comme l'adaptation du routage H5, certains composants incompatibles, et même l'adaptation à la fenêtre. L'emplacement est bien.

À partir des solutions présentées ci-dessus, nous pouvons réaliser que le secret de base pour traiter ces facteurs est les deux phrases suivantes:

La première phrase: adapter les mesures aux conditions locales et trouver un équilibre.

Deuxième phrase: améliorer la réutilisation et réduire les changements.

5. Innovation

Il y a un dicton qui va comme ceci: la grandeur naît dans l'ordinaire . Mettons les choses ici, disons les choses autrement, c'est-à-dire que l'  innovation se reproduit dans la pratique .

Au cours de la pratique, nous avons résolu de nombreux problèmes. Dans le processus de résolution du problème, nous avons fait quelques heureuses innovations.

• innovation vuex

Cette innovation vient d'un problème dont le contexte est le suivant:

La page de détail du produit du centre commercial H5 utilise vuex pour gérer les données. Lorsque vuex est déplacée vers la page de détail du produit du mini-programme, un phénomène est détecté, comme illustré dans l'animation suivante:

À partir de l'animation ci-dessus, nous constatons que lors de l'utilisation de vuex, nous cliquons sur le produit B de la page de détail du produit A pour accéder à la page de détail du produit de B. À ce stade, nous cliquons sur le coin supérieur gauche pour revenir à la page de détails du produit de A, et nous constaterons que la page de détails du produit a changé pour le produit B pour le moment, c'est-à-dire que les données du produit A ont disparu.

C'est un très gros problème. Après enquête, les raisons sont les suivantes:

L'espace de noms par défaut de vuex est un, et l'espace de noms ne peut pas être ajouté automatiquement. Lorsque vous utilisez vuex pour la gestion des données dans la page de l'applet, en raison du mécanisme de données de la page de l'applet, lorsque vous cliquez pour revenir, les données de la page utilisent les mêmes données vuex, ce qui conduit au phénomène ci-dessus.

Ici, quelqu'un pourrait dire que dans le cycle de vie onShow, l'actualisation des données résoudra le problème. En fait, ce n'est pas le cas. Dans ce scénario, l'actualisation des données est très déraisonnable.

Alors, comment le résoudre?

Nous savons qu'après avoir utilisé vuex, les données de la page de l'applet auront des problèmes d'affichage après avoir entré plusieurs fois la même page. Par la suite, le groupe a discuté, après une analyse approfondie, a décidé de continuer à utiliser vuex et de résoudre ce problème en ajoutant une couche d'adaptation à vuex.

Par la suite, le groupe a eu une discussion, et après un bilan global, il a été décidé de continuer à utiliser vuex. Ce problème est résolu en ajoutant une couche d'adaptation à vuex.

Tout d'abord, voyons ce qui se passe après l'ajout d'une couche d'adaptation à vuex et l'exécution des opérations ci-dessus.

Comme le montre l'animation ci-dessous:

À partir de l'animation ci-dessus, nous pouvons le constater après avoir ajouté une couche d'adaptation à vuex. Résolution du problème d'affichage des données de petites pages de programme après avoir utilisé vuex, après avoir entré plusieurs fois la même page et avoir cliqué en arrière.

Comment avons-nous résolu ce problème?

Solution principale: une solution de gestion des flux de données plus intelligente peut être obtenue en laissant vuex prendre en charge l'expansion automatique et l'annulation automatique de l'espace de noms .

Le diagramme d'architecture de base est le suivant

En générant automatiquement l'espace de noms dans le magasin, il est garanti que les données de chaque page sont conservées après que la même page est entrée plusieurs fois. Lorsque la page revient, l'association d'espace de noms des composants parent et enfant est terminée en collectant dynamiquement l'espace de noms du composant parent.

Grâce aux solutions techniques ci-dessus, nous avons résolu les problèmes qui existaient lorsque vuex était utilisé dans de petits programmes. Ici, le schéma d'architecture de base a été donné, et l'implémentation spécifique ne sera pas décrite en détail.

6. Découplage de l'innovation

Cette innovation vient d'un problème dont le contexte est le suivant:

Nous avons maintenant des pages de détails sur les produits pour les produits courants, de pointe et de jonction de groupe, et il y aura d'autres pages de détails sur les produits plus tard, alors comment réutiliser les composants métier dans ces pages de détails?

Face aux problèmes ci-dessus, chacun aura les réflexions suivantes:

• Différentes pages, le traitement des données dans les composants métier sont différents

• Différentes pages, les points enfouis dans les composants métier sont différents

• Différentes pages, il peut y avoir des demandes d'interface spécifiques dans les composants métier

Tout le monde doit toucher aux idées ci-dessus: la réutilisation des composants métier en soi est une chose très difficile, et c'est encore plus difficile si vous voulez complètement découpler.

Alors, comment pouvons-nous atteindre le plus découplé possible?

Nous avons fait ce qui suit:

1. Assurer l'unification des points enfouis en amont et réaliser l'unification des points enfouis en concevant les points enfouis au niveau des composants.
2. Au niveau des composants, des jugements conditionnels sont faits pour des interfaces spécifiques.
3. Les données du composant métier sont décomposées en données source et données dérivées. Les données source sont cohérentes au niveau vuex et les données dérivées sont adaptées en conséquence dans le composant métier en fonction de la situation réelle.
4. Rénovez vuex pour découpler complètement la communication entre les composants métier et les pages, et les composants métier n'ont plus besoin de connaître l'espace de noms vuex de la page.

Les étudiants qui ont développé le projet de centre commercial doivent savoir que la logique de la couche de bombe sélectionnée est très compliquée. Ici, nous prendrons le composant métier de couche de bombe sélectionné comme exemple pour illustrer comment nous réutiliserons les composants métier.

Voici la composition des composants de la couche de bombe sélectionnés qui ont été réutilisés:

├── components
│   ├── sku-number
│   ├── sku-product
│   ├── sku-service
│   ├── sku-spec
│   └── ...
├── index.js
├── index.scss
├── index.vue
├── mutation-types.js
└── track.js

Nous divisons les données des composants de la couche de bombe sélectionnés en données source et données dérivées. Les données source sont unifiées au niveau vuex, comme illustré dans la figure suivante:

Nous écrivons une vuex pour chaque page de détail, et en même temps extrayons la même partie en détail commun. Après cela, nous traitons en vuex pour nous assurer que les données source fournies par différentes pages sont les mêmes. Ces données source doivent être transmises aux composants métier.

Comme indiqué dans le code suivant:

// 这是已选弹层业务组件
// 通过 @vivo/smartx 解耦组件和页面的通信
import { mapState, mapGetters, mapMutations, mapActions } from '@vivo/smartx'

// 获取源数据
computed: {
  ...mapState([
    'spuInfo',
    'skuInfo'
  ]),
  ...mapGetters([
    'price',
    'pageType'
  ]),
}

methods: {
  fn() {
    // 策略模式
  }
}

Grâce au traitement ci-dessus, des composants métier similaires peuvent être bien découplés des différentes pages, améliorant ainsi la réutilisabilité, la maintenabilité et l'évolutivité du code.

Cette idée de découplage des composants métier réside dans:

Il n'est pas nécessaire de séparer délibérément les données et la vue complètement. Grâce aux données source et aux données dérivées, les données modifiées et les données immuables sont équilibrées, puis grâce à @ vivo / smartx auto-développé, le changement deviendra un îlot et le changement deviendra un îlot. Île isolée.

Chaque innovation est un test, elle vous donne toujours par inadvertance des difficultés, puis vous oblige à vous percer, créant ainsi de meilleures choses, répétant le cycle.

Enfin, le mini programme multi-terminal WeChat du centre commercial officiel de vivo a été lancé. Vous pouvez cliquer sur la boutique officielle vivo pour en faire l' expérience.

Six, résumé

Dans cet article, nous avons passé en revue ensemble la route unifiée multi-extrémité des applets WeChat in vivo mall. Des besoins commerciaux, de la valeur d'existence à la pratique technique et à l'innovation, nous espérons utiliser la technologie pour rendre la route à plusieurs extrémités plus fluide.

Équipe frontale du centre commercial du site officiel de Vivo