Chemin de mise à niveau de l'expérience de la page de détails de la commande du service client

17109204 :

1. Origines

En tant que l'une des pages les plus visitées dans le domaine du service client, la page des détails de la commande est utilisée pour vérifier les informations de commande de l'utilisateur dans le travail quotidien du service client, afin de fournir de meilleurs services d'achat aux acheteurs et vendeurs entrants, améliorant ainsi la satisfaction des utilisateurs. .Dépenser. Qu'il s'agisse du service client de première ou de deuxième ligne ou des responsables du service client, ils peuvent accéder directement à la page de détails dans le système qu'ils utilisent quotidiennement. Il existe donc de nombreuses entrées vers la page de détails des commandes du service client, actuellement plus de 10 .

Avec le développement rapide des activités de Dewu, la page de détails des commandes du service client doit afficher de plus en plus d'informations et de plus en plus d'opérations doivent être prises en charge. Avant la révision de la page, le premier écran d'une page devait afficher 80 pièces de commande. Plus précisément, la quantité changera en fonction du type de commande, de l'état de la transaction, de l'état logistique et d'autres facteurs. Une page peut contenir jusqu'à 200 informations, 60 boutons et 20 balises de commande (hors balises utilisateur et balises produit) , il y aura donc un phénomène qu'un moniteur avec une résolution de 1920*1080 (une résolution couramment utilisée par le service client ), La molette de la souris doit être tournée deux fois pour glisser du haut vers le bas de la page. La capture d'écran des informations de la page de détails est présentée ci-dessous.

D’un autre côté, des ajustements précipités réduiront l’efficacité du travail des étudiants en service client. Les énormes changements dans le contenu des pages et les interactions imposent également des coûts de formation considérables aux étudiants en service client. Par conséquent, conformément au principe de minimiser l'impact des changements, la quantité d'informations n'a fait qu'augmenter au lieu de diminuer .

Après une période de précipitation et de perfectionnement, l'expérience du service client et l'expérience de développement sur la page des détails de la commande du service client ont été considérablement améliorées, et les problèmes TS liés aux commandes sont restés résolus au cours des six derniers mois . Au cours de cette période, de nombreuses tentatives et optimisations progressives ont été faites.Cet article parle principalement de quelques réflexions et optimisations sur la mise à niveau de l'expérience de la page de détails des commandes du service client à partir des trois points suivants.

• Avec une page d'informations aussi complète, presque toutes les plates-formes du domaine du service client doivent pouvoir y accéder directement.Comment utiliser une page dans plusieurs systèmes peut non seulement garantir l'expérience utilisateur des étudiants du service client, mais également économiser les étudiants en développement et les coûts de maintenance .

• La grande quantité d'informations et les multiples sources de données entraînent un chargement lent de la page. Les étudiants en service client signalent souvent que la page est bloquée. Comment optimiser le premier écran de la page pour qu'il s'ouvre en quelques secondes afin d'améliorer encore l'expérience utilisateur du client. étudiants en service .

• Des changements simples nécessitent également un investissement de ressources et le taux de réutilisation des modules d'information est faible.Comment développer la capacité d'organiser librement les informations et de brancher et débrancher les modules d'information pour maximiser la productivité des étudiants de l'industrie, de la recherche et des transports .

‍

2. Réutilisation de pages avec plusieurs entrées

1. Iframe multi-instance

La première page de détails de la commande n'était qu'une page du système de bons de travail du service client, utilisant la pile technologique de Vue2 et ElementUI. Le système de bons de travail du service client se positionne comme un système de gestion back-end avec un seuil d'utilisation élevé et est plus adapté aux gestionnaires. Par conséquent, une plate-forme pour le service client de première et de deuxième ligne est nécessaire, et Octopus Workbench est né. L'Octopus Workbench est construit sur la base de la micro-application qiankun. Ses sous-applications utilisaient initialement Vue3, Vite et Ant Design. À cette époque, si vous vouliez accéder à la page de détails des commandes du service client dans Octopus Workbench, c'était un croisement -communication entre applications et pile technologique. L'utilisation d'iframe était le moyen le moins coûteux et le plus approprié au début est également la première étape utiliser plusieurs conteneurs iframe dans une sous-application pour intégrer la page de détails de la commande dans le système de bons de travail .

Tous les utilisateurs de la page de détails de la commande doivent uniquement créer un conteneur iframe localement, puis transmettre certains paramètres nécessaires tels que le numéro de commande et le numéro de bon de commande lors de l'intégration de l'adresse d'accès de la page de détails de la commande, puis ils peuvent y accéder normalement, ce qui est très pratique. Il peut également prendre en charge certaines configurations avancées que les utilisateurs peuvent choisir, telles que la prise en charge du contrôle du style de page via les paramètres de requête d'URL, le masquage du menu et de la barre d'onglets supérieure de l'application principale lorsqu'elle est utilisée pour une intégration externe, etc.

A ce stade, le problème de la réutilisation des pages est dans un premier temps résolu . Mais tout le monde connaît les inconvénients des iframes. Un grand nombre de changements de page se produiront dans le travail quotidien des étudiants du service client de première et deuxième lignes, ce qui amplifie les défauts des iframes, tels qu'une utilisation élevée de la mémoire et un chargement lent. À ce stade, le personnel du service client de première et de deuxième ligne est souvent bloqué. La page de commentaires est souvent bloquée, une optimisation plus poussée est donc nécessaire de toute urgence.

2. Iframe à instance unique avec composant distant MF

Après avoir analysé les caractéristiques des utilisateurs et les comportements de travail du système de bons de travail du service client et d'Octopus Workbench, il a été constaté que les utilisateurs d'Octopus Workbench ont des exigences plus élevées en matière d'expérience de page, de sorte que la page de détails a été optimisée pour la première fois et est entrée dans la troisième étape . Deuxième étape : La page de détails de la commande est migrée vers l'atelier des bons de travail Octopus, et sa méthode de construction est également modifiée de Vite à Webpack5. La fonctionnalité de fédération de modules de Webpack5 est utilisée pour communiquer des données entre les sous-applications via des composants distants . D'un autre côté, malgré les défauts évidents de l'iframe, il reste un bon choix pour la communication de pages entre les applications à travers les piles technologiques. Le contrôle de l'iframe dans un conteneur à instance unique peut limiter au maximum son utilisation de la mémoire.

De cette façon, bien qu'il y ait plus de 10 entrées vers la page de détails, les méthodes de communication sont condensées en trois types : composants distants, iframes à instance unique et composants locaux. Tous les scénarios peuvent être couverts. Les modifications interactives complexes ultérieures ou les événements personnalisés à chaque entrée peuvent être surveillés et fermés sur la page principale, sans nécessiter de développement supplémentaire de la part de l'utilisateur de la page .

3. Mise en œuvre technique

3.1.Communication iframe à instance unique

Fournisseur de contenu

• Enregistrez l'événement de message une fois que l'interface de détails a répondu.

• Surveillez les modifications apportées aux données portées par le parent iframe et mettez à jour les données de la page locale.

• L'événement d'interaction de page locale est déclenché par l'extrémité distante et les données actuelles sont envoyées à l'extrémité distante pour une interaction personnalisée.

/** Vue3 */
/** 1. 详情接口响应后注册message事件 */
onMounted(() => {
   /** 请求详情接口 */
  fetchOrderDetail(() => {
    /** query上打上iframe标签，用于确定注册时机 */
    route.query.iframeRoute && watchParentMessage()
  })
})

/** 2. 监听iframe父级携带数据变化，更新本地页面数据 */
const watchParentMessage = () => {
  window.addEventListener('message', event => {
    const orderNo = event.data.data.orderNo
    if (event.data.type === 'ORDER_CHANGE' && orderNo) {
      /** 更新订单信息*/
      initStream(orderNo)
    }
  })
}
/** 3. 本地页面交互事件被远端触发，发送当前的数据给远端 */
window.parent.postMessage(
  /** payload: 携带的数据*/
  {
    type: 'workbenchRoute',
    params: {
      /** 跳转退货详情页 */
      name: 'refundDetail',
      query: {
        // 携带数据
      },
    },
  },
  /** orgin: 如果想要传递给任意窗口，可以将这个参数设置为'*' ，为了安全起见，不建议设置为'*'*/
  '*'
)

Utilisateurs de contenu

• Enregistrez l'événement de message lorsque la page est initialisée.

• Surveillez les modifications des numéros de commande locaux et envoyez de nouvelles données à l’extrémité distante.

• Surveillez les interactions à distance et les modifications de données, et effectuez différents traitements locaux en fonction du type d'interaction.

/** Vue2 */

/** 1. 页面初始化时注册message事件*/
mounted() {
    window.addEventListener('message', this.callBack, false)
},
/** 2. 监听本地订单单号变化，将新的数据传给远端*/
watch: {
    orderNo(newOrderNo) {
        /** 在iframe的contentWindow属性上挂载postMessage方法*/
       detailIframeRef.contentWindow.postMessage(
        /** payload: 携带的数据*/
        {
          type: 'ORDER_CHANGE',
          data: {
            orderNo：newOrderNo,
            //其他数据
          },
        },
        /** orgin: 如果想要传递给任意窗口，可以将这个参数设置为'*' ，为了安全起见，不建议设置为'*'*/
        '*',
      )
    },
},
/** 3. 监听远端交互和数据变化，根据交互类型做不同的本地处理 */
method: {
    /** callBack: 远端事件被触发后，处理本地回调逻辑 */
    callBack(event) {
      try {
        if (event.data.type === 'workbenchRoute') {
         switch (event.data.params.name) {
            case 'orderdetail':
              //跳转订单详情的handler
              break
            case 'detail':
              //跳转工单详情的handler
              break
            // 其他交互
            default: 
              //兜底处理
          }
        }
    } catch(error) {
      //异常处理
    }
}

3.2. Communication des composants distants

Fournisseur de contenu

• Configurez le plug-in MF du webpack pour exposer l'intégralité de la page de détails de la commande

• Maintenir les accessoires de la page de détails

‍

/** 配置webpack MF插件，将订单详情页exposes出去*/
 new ModuleFederationPlugin({
    filename: 'remoteEntry.js?[hash]',
    library: { type: 'window', name: 'app_ticket' },
    name: 'app_ticket',
    shared: {
    /** 需要共享的依赖 */
    },
    exposes: {
        /** 提供订单详情远程组件*/
      './OrderDetail': './src/views/orderdetail/Index.tsx',
    },
  }),

Utilisateurs de contenu

• webpack configure les applications distantes qui nécessitent une communication

• Enregistrez un composant à l'aide de DefineAsyncComponent

• Utiliser des composants distants comme des composants locaux

/** 1.webpack配置远端应用 */
remotes: {
  app_ticket: getRemoteUrl('app_ticket'),
},
/** 2. 使用defineAsyncComponent注册组件*/
'OrderDetail': defineAsyncComponent(() => import('app_ticket/OrderDetail')),
/** 3. 像本地组件一样使用远程组件*/
<OrderDetail orderNo={orderNo} {...props} />

4. Résumé

Le premier écran de la page utilisant iframe prend en moyenne 7 076 ms et le deuxième écran prend 2 594 ms. Cependant, le premier écran de MF ne prend que 1 279 ms et le deuxième écran ne prend que 428 ms. Le temps de rendu est réduit de 6 fois .

L'utilisation de la mémoire d'une seule page a été réduite à moins de 1/10 de la précédente. Pour plus de détails sur la fédération de modules et les composants distants, vous pouvez consulter les meilleures pratiques de la fédération de modules dans le secteur des tickets de service client Dewu .

3. Optimisation de l'ouverture du premier écran en quelques secondes

Le chapitre précédent mentionnait que l'utilisation de MF résout le problème de latence au niveau architectural. Cependant, sans mise en cache, la page prend encore 2 à 3 secondes, voire plus, pour afficher les informations de commande. Que devons-nous faire dans ce cas ? Oui, vous pouvez modifier l'interaction et démonter l'interface. Mais si les données dépendent d’un grand nombre de services externes, sans l’intervention de ressources externes de l’industrie et de la recherche, et doivent être efficacement optimisées en une semaine, que peut-on faire d’autre ?

1. Raisons de la lenteur

Pour des raisons historiques, la page des détails de la commande du service client doit afficher plus de 100 informations de commande en même temps. Toutes les informations de commande et les opérations de commande impliquent près de 200 champs, et 90 % de ces champs sont dans une interface http. Cette grande interface contient Il dispose de 36 interfaces Dubbo , qui proviennent des transactions avant, arrière, de la chaîne d'approvisionnement, des commerçants, des produits, des utilisateurs et d'autres BU. Les appels parallèles auront certainement un effet négatif. Tant qu'une interface a un RT (temps de réaction, temps de réponse) lent, cela ralentira la vitesse de réponse de l'ensemble de l'interface http. Dans le même temps, la probabilité d'expiration sera également De plus, la page elle-même a Le temps de rendu des ressources, sans mise en cache, prend encore 2 à 3 secondes voire plus pour actualiser les informations de commande. Le RT moyen de cette grande interface est de 500 ms, et le RT de la ligne P99 atteint 1,3 s . L'image ci-dessous montre les détails d'un certain appel dans l'environnement de production, qui prend 782 ms. Il est urgent de réduire le RT et d'optimiser le premier rendu à l'écran.

En plus du problème fastidieux de l'interface RT, il existe également le problème de l'appel parallèle des interfaces du premier écran. 90 % des champs se trouvent dans une grande interface et les 10 % restants sont dans de petites interfaces dispersées. En additionnant ces petites interfaces, il y a plus de 6 interfaces de premier écran sur la page . Nous savons qu'un onglet Chrome peut traiter jusqu'à 6 requêtes http en parallèle. S'il existe une 7ème interface, elle entrera dans l'état Bloqué et attendra la réponse d'une interface précédente avant de lancer une requête. La figure suivante est un exemple, getTrackTicketInfo L'interface est la septième interface sur le premier écran de la page, et 255,14 ms est le temps d'attente.

Sur la base de la situation actuelle du problème ci-dessus, le plan préliminaire est d'agréger d'abord les interfaces, puis de les diviser , de regrouper les données de toutes les interfaces en une seule, puis de les diviser en plusieurs interfaces selon le module d'information. puis divisez-les en fonction des scénarios commerciaux et des comportements des utilisateurs.Optimisez le timing des appels de l'interface sortante. Cependant, l'idéal est très complet, la réalité est très maigre, et la quantité de données est là, il est difficile de le faire en peu de temps. Il a fallu deux jours pour trier tous les champs et trier les sources de données. Après avoir examiné les coûts et les avantages, notre plan final était d'ajouter une nouvelle interface rapide et lente . Le RT de l'interface rapide devrait être dans les 200 ms, et tout le RT qui a ralenti RT Les données sont placées dans l'interface lente, et le front-end divise toutes les interfaces en deux échelons en fonction des caractéristiques de l'interface et les appelle à des moments différents , minimisant ainsi le temps de rendu du premier écran de la page.

2. Optimisation des appels d'interface

2.1.Solutions techniques

Afin de contrôler le nombre d'interfaces de requête parallèle de page et le nombre de temps de rendu des données de page, toutes les petites interfaces dispersées, à l'exception des interfaces rapides et lentes, sont divisées en deux échelons suivants : interfaces d'informations sur le premier écran qui ne dépendent pas sur les anti-paramètres de l'interface de grands détails;ceux qui reposent sur les anti-paramètres des grandes interfaces de détails L'interface d'informations sur le premier écran et l'interface d'informations sur non-premier écran .

Le diagramme schématique du premier appel d'interface d'écran de la page de détails finale est le suivant. Lorsque la première interface d'informations d'écran qui repose sur de grands anti-paramètres d'interface peut être agrégée, la page ne sera rendue que deux fois. La première fois est demandée en retour. par l'interface de détails rapides et l'interface du premier échelon. Après cela (utilisez Promise.all pour contrôler le timing de rendu des données), la deuxième fois est après le retour de la demande d'interface de détails lente.

Utilisez Promise.all pour garantir que l'interface de détails rapides et les informations de l'interface de premier niveau sont rendues en même temps, réduisant ainsi le nombre de rendus de page et réduisant ainsi la gigue des pages. Un inconvénient de Promise.all est qu'il contient une exception Promise et que l'exception entière sera levée. Par conséquent, la promesse enveloppée dans Promise.all doit être réencapsulée pour garantir qu'une erreur de promesse n'interférera pas avec les requêtes. à partir d'autres interfaces. Implémentation de code spécifique Voici comment procéder :

/** 处理promise，保证promise.all使用时相互独立 */
export const handlerPromise = (api, params) => {
  return new Promise(resolve => {
    api(params)
      .then(resolve)
      .catch(() => resolve({ error: true }))
  })
}

/** 详情页首屏请求函数 */
 const fetchOrderDetail = (callback?) => {
 /** 使用handlerPromise封装过的promise，保证有一个报错不干扰其他接口请求 */
  Promise.all([quickDetail(), firstLevel1(), firstLevel2()])
    .then(([quickDetailData, firstLevelData1, firstLevelData2]) => {
      // 快详情接口
      !quickDetailData?.error && quickDetailHandler(quickDetailData)
      // 第一梯队接口调用：不依赖详情反参的首屏信息接口
      !firstLevelData1?.error && firstLevelHandler1(firstLevelData1)
      !firstLevelData2?.error && firstLevelHandler2(firstLevelData2)
      // 执行回调
      nextTick(callback)
    })
    .then(() => {
      // 第二梯队接口调用：依赖详情反参的首屏信息接口、非首屏接口
        secondLevelHandler1()
        secondLevelHandler2()
    })
  // 执行慢接口
  fetchSlowOrderDetail()
}

Il y a encore une chose à noter après avoir confirmé la séquence d'appel de l'interface, car l'interface lente met beaucoup de temps à répondre. Dans un scénario de travail où les étudiants du service client interrogent rapidement, la commande suivante peut être basculée vers la page pendant que l'interface lente est toujours en attente. Dans le scénario de l'instance, si elle n'est pas traitée à ce moment-là, une sérialisation des données peut se produire et des données qui n'appartiennent pas à la commande seront affichées. À ce sujet, le traitement suivant doit être effectué sur le gestionnaire de l'interface lente .

/** 慢详情接口请求 */
 const fetchSlowOrderDetail = () => {
      slowLoading.value = true
      orderApi
        .getDetail(params)
        .then(slowData => {
          /** 防止快速切换订单导致的数据串台问题 */
          if (slowData?.topInfo?.orderNo === orderNo.value) {
            orderDetail.value = slowData
          }
          slowLoading.value = false
        })
        .catch(() => {
          slowLoading.value = false
        })
    }

2.2. Effet final

Le diagramme en cascade optimisé est tel qu'illustré ci-dessous. Le temps de blocage gris n'apparaîtra plus et les données sur le premier écran ont été demandées après 228 ms.

3. Optimisation de grande interface

Le point ci-dessus résout le problème de l'appel de l'interface du premier écran. Ensuite, il y a une optimisation spécifique de l'interface des grands détails :

• Le protocole d'interface passe de POST à ​​la requête GET . La durée totale de GET est les deux tiers du POST. S'il est détecté que la requête GET est une ressource statique sous Chrome, elle sera mise en cache. Si les données transmises deux fois sont les De même, les données seront mises en cache après la deuxième fois. Le temps consommé sera dans les 10 ms. D'autre part, cela pose également les bases de l'introduction ultérieure de la technologie Service Worker dans l'atelier.

• Une nouvelle interface de détails rapides est ajoutée pour trier les champs à temps de réponse élevé dans la grande interface. L'interface rapide ne contient plus ces champs. Ces champs très chronophages ont un nouvel effet de chargement au niveau du champ. Afin d'éviter la grande différence de consommation de temps entre les interfaces rapides et lentes, certains étudiants expérimentés du service client croient à tort que les champs qui ne renvoient pas de données depuis l'interface rapide sont des données vides. Cependant, cette quantité de chargement ne dépassera pas 3 emplacements, gardera la page propre et facile à lire.

4. Résumé

Après l'optimisation ci-dessus, l'interface de détail rapide RT ne prend en moyenne que 190 ms, soit une baisse de 41 % par rapport aux 470 ms de la grande interface précédente. Le temps de rendu du premier écran est passé de 873 ms à 376 ms , soit une baisse de 57 % , et le 95e le percentile était de 567 ms, soit une baisse de 62 % .

L'effet d'optimisation du premier écran est évident, et il est difficile de voir le VOC que la page de détails des commentaires se charge lentement, ce qui améliore dans une certaine mesure la satisfaction de l'expérience de la plate-forme de service client.

4. Disposition des informations et renforcement des capacités des plug-ins de modèles

Le problème du décalage de page et du chargement lent du premier écran a été résolu, mais il reste encore quelques problèmes. Cette fois, avec la pleine collaboration des étudiants de l'industrie, de la recherche et des transports, comment pouvons-nous améliorer davantage l'expérience de développement des étudiants en technique et l'expérience d'utilisation des étudiants en service client ?

1. Problèmes toujours rencontrés

Bien qu'il y ait jusqu'à 200 champs empilés sur la page de détails, avec le développement rapide des affaires, il y aura encore des informations manquantes et inexactes, ce qui aura un certain impact négatif sur les opérations quotidiennes du service client. D'autre part, environ 60 % du développement des exigences de commande consiste à ajouter, supprimer ou modifier des champs en conjonction avec des domaines externes ou en interne. Si la capacité d'organiser les informations de commande est établie, les exigences de champ ultérieures seront configurables, libérant ainsi ce Une partie des exigences. La productivité de la production et de la recherche peut être atteinte pour réduire les coûts et augmenter l'efficacité ; en même temps, si le module frontal peut prendre en charge les capacités de plug-in du module, il peut également fournir un support technique pour les modules d'information sur les commandes ultérieures. être réutilisé dans l'assistance aux agents et dans d'autres ateliers de service client.

2. Renforcement des capacités d’orchestration de l’information

Conservez les informations de base de la commande et les informations associées via un schéma unifié . Comme nous le savons tous, Schema (type de données structurées) peut être utilisé pour décrire des données dans tous les scénarios à condition que l'accord soit suffisamment complexe. Par conséquent, la première étape de l'utilisation de Schema est de bien contrôler cette frontière. Elle ne doit pas être trop étroite. tout en couvrant la plupart des scénarios commerciaux complexes. Premièrement, les informations de commande peuvent être subdivisées en trois niveaux : blocs d'informations, groupes d'informations et éléments d'informations. La configuration des blocs d'informations et des éléments d'information n'est pas adaptée au scénario de la page de détails de la commande, nous choisissons donc ici le format du groupe d'informations.

2.1. Format du schéma

Les deux ensembles de groupes d'informations dans la figure ci-dessus peuvent être décrits par le schéma suivant.L'ordre du tableau est utilisé pour restituer les groupes d'informations de gauche à droite et de haut en bas afin d'obtenir la possibilité d'organiser et de configurer les informations de commande.

schemaData : [
    {
        label: '订单类型'
        text：'普通现货'
        children: [
            {
                id: 'orderTypeDetail'
                text: '详情',
                show: true,
                toolType: 'linkBtn', /** linkBtn, primaryBtn, tag */
                eventType: 'click', /** dbclick, hover*/
                interactiveType: 'popover', /** modal， popover， message*/   
                children: [
                     //** popover弹出的内容 */
                    { label: , text: '', children: //..}]
                    { label: , text: ''}
                ]   
            },
            {
                text: '晚到必赔',
                show: true
                toolType: 'tag', 
            },
            {
                text: '退运服务',
                show: true
                toolType: 'tag', 
            },
        ]
    },
    {
        id: 'tradeStatus'
        label: '支付状态'
        text：'已经支付'
        children: [
           {
                text: '七天风控',
                show: true
                toolType: 'tag', 
            },
        ]
    }
],

2.2 Configuration avancée

L'utilisation de Schema peut satisfaire la plupart des scénarios de rendu de champ, mais certaines interactions complexes et styles personnalisés doivent encore être implémentés par le front-end. À ce stade, l'identifiant de chaque élément d'information entre en jeu et le front-end peut lier l'interaction en fonction de l'identifiant . Les événements et les styles personnalisés sont implémentés comme suit :

/** 信息元素枚举*/
enum INFO_ElEMENT_MAP {
    /** 订单类型详情按钮 */
    ORDERTYPE_DETAIL: 'orderTypeDetail'

}

/** 信息元素*/
const infoElementMap = {
        INFO_ElEMENT_MAP.ORDERTYPE_DETAIL: {
            /** 绑定事件 */
            onClick: () => {
                orderTypeDetailClickHandler()
            },
            /** 绑定样式 */
            className: [styles.marginLeft],
        },
      /** 其他需要添加复杂交互和样式*/
    }

2.3. Analyse du modèle

Après avoir accepté le schéma et les spécifications, le front-end écrit le code d'analyse du modèle correspondant pour restituer la page . Le rendu correspondant est comme indiqué ci-dessous.

Le code du moteur de rendu le plus externe est le suivant :

const SchemaRender = () => {
     //TODO 健壮性代码
      return (
        <div>
          {schemaData.length ? (
            <Row>
              {schemaTemplate.map(item => {
                // 分隔符 
                if (item.key === TemplateKeyEnum.dividedLine) {
                  return <Divider />
                }
                return (
                  <Col span={12}>
                    <InfoItem
                      key={item.key}
                      label={item.label}
                      text={item.text}
                      infoList={item.children.map(child => {
                        return {
                          text: popoverRender(child),
                          hide: !child.show,
                        }
                      })}
                    />
                  </Col>
                )
              })}
            </Row>
          ) : (
            <Skeleton title={false} active paragraph={{ rows: 3 }} />
          )}
        </div>
      )
    }

Enfin, le rendu du modèle Schema plus peut restituer les informations de la page de détails de la commande. En plus de convenir des champs avec des domaines externes, les exigences ultérieures de ce type ne nécessitent pas d'investissement en ressources supplémentaires .

3. Création de capacités plug-and-pull de module

Il permet un agencement rapide des informations et résout le problème du couplage élevé des modules d'informations. En fait, les étudiants en service client ayant des rôles différents se concentrent sur des informations différentes, de sorte que la nouvelle page de détails de la commande doit afficher des informations différentes en fonction de l'identité du service client ; et avec différentes tailles d'écran, les mises en page appropriées sont également différentes. D'un autre côté, les détails de l'ordre de travail et l'assistance de l'agent doivent tous afficher un certain module d'informations sur les commandes (afficher la page entière serait trop lourd). Dans ce cas, le module d'informations sur les commandes doit être enfichable.

3.1.Solutions techniques

Le plan préliminaire est de maintenir un pool de modules d'information au niveau du back-end et de fournir une interface.Le front-end peut renvoyer la combinaison de modules requise par l'identification correspondante en passant un identifiant, puis restituer les données en fonction de la combinaison de données. Cette solution permet d'obtenir l'enfichage des informations.

La solution ci-dessus peut résoudre le problème et est relativement simple, mais c'est le frontal qui contrôle les données, ce qui va en réalité à l'encontre de l'intention initiale de créer des capacités d'orchestration des informations. Ainsi, en fin de compte, les étudiants du back-end ont obtenu l'ID utilisateur à partir du statut de connexion de l'étudiant du service client et ont obtenu le groupe de traitement en fonction de l'ID. S'il s'agissait du groupe de traitement de l'acheteur, la version de l'acheteur des informations de commande a été renvoyée et La version du vendeur a renvoyé la version du vendeur des informations de commande. D’autre part, le front-end adapte également la mise en page en fonction de la taille de l’écran.

3.2. Effet final

• Mise en page sous grand écran :

• Mise en page sous petit écran (inférieur à 1440*900) :

• Pour les détails de l'ordre de travail, utilisez les modules d'informations sur les commandes d'enregistrement logistique et d'enregistrement de service dans les détails de la commande :

À en juger par les données d'investissement dans les ressources de près de 8 itérations depuis la révision, le coût du développement de la demande de commandes a été réduit de 66,7 % .

5. Solutions en niveaux de gris et points enterrés

1. Solution en niveaux de gris

La nouvelle version de la page de détails présente des changements majeurs et doit être mise en niveaux de gris en fonction du groupe de traitement où se trouve le service client. Cependant, l'attribution des groupes de traitement dans la première et la deuxième ligne est différente, il est donc nécessaire de déterminer lequel Interface de la solution AB à utiliser en fonction de la source d'entrée . Par contre, il y a de nombreuses entrées dans la page de détails de la commande, il n'est donc pas pratique de faire des niveaux de gris à chaque entrée, et les changements seront importants, nous choisissons donc de fermer la page principale de la page de détails pour distinguer l'ancienne. et de nouvelles pages .

1.1.Solutions techniques

• Selon la source, on utilise le plan AB de première intention ou le plan AB de deuxième intention, le pseudo-code est le suivant :

/** 获取来源区分IM、工单灰度组信息 */
watch(
  () => props.platformCode,
  code => {
    try {
     switch (code) {
       case PLATFORM_TYPE.IM:
         /** 一线灰度走一线灰度接口 */
        isGray.value = true
        break
       case PLATFORM_TYPE.TICKET:
        /** 二线灰度走二线灰度接口 */
        isGray.value = true
        break
       default:
        isGray.value = false
    } catch {
      isGray.value = false
    }
  },
  {
    immediate: true,
  }
)

• Rendre le modèle de détail selon les niveaux de gris sur la page principale :

return () => isGray.value ? (
    <>
      <Button type="link" onClick={clickHandler} >
        返回{isOld.value ? '新版' : '老版'}
      </Button>
      {isOld.value ? <OldDetail {...props} /> : <Detail {...props} />}
    </>
  ) : <OldDetail {...props} />

1.2. Résumé

En fonction de l'avancement de la formation, la liste des niveaux de gris sera ouverte pour que le service client puisse utiliser la nouvelle version de la page, et les données des nouvelles et anciennes versions de la page seront surveillées en même temps. Il prend en charge la surveillance, les niveaux de gris et la restauration, garantissant ainsi une qualité stable du système en cas de modifications majeures des pages.

2. Plan enterré

Afin de refléter les avantages et la valeur de l'optimisation des informations sur les commandes, il est nécessaire de comparer le temps pendant lequel les étudiants du service client restent sur les nouvelles et anciennes pages de détails de commande et le nombre de fois qu'ils sortent des pages de détails de commande.

• Temps de séjour sur la page de détail de la commande : Plus le temps de séjour effectif est long, plus il est difficile de visualiser la page.

• Taux de rebond de la page des détails de la commande : Plus le taux de rebond est élevé, cela signifie que les détails de la commande actuelle ne peuvent pas répondre aux besoins de requête du service client et que vous devez accéder à d'autres pages pour les consulter. C'est une manifestation d'informations incomplètes et peu claires. De plus, sauter hors de la page rechargera une nouvelle page, et le temps d'attente sera plus long que l'obtention des informations sur la page, ce qui augmente le temps nécessaire au service client pour obtenir des informations.

2.1. Temps de séjour des pages

Utilisez la méthode de l’itinéraire d’écoute pour calculer le temps d’attente de la page. Un seul d’entre eux est analysé ici, les deux autres sont similaires.

• Déterminer l'itinéraire : https://xxx-xxx.xxx/orderdetail/:id

• Il vous suffit de considérer la situation où l'itinéraire précédent est la page de commande

• Filtrage des données : moins de 3 s, plus de 30 min sont considérées comme des données invalides

• Si l'itinéraire le plus récent est la page de commande, réinitialisez l'heure

/** 数据上报 */
const uplog = (current, last, constant, type) => {
  /** b: 只用考虑上一个路由是订单页面的情况 */
  if (constant === last) {
    const nowTime = getNowTime()
    const stayTime = nowTime - stayOrderDetailTime.currentTime
    /** c: 小于3s，大于30min视为无效数据 */
    if (stayTime > 3000 && stayTime < 1000 * 60 * 30) {
      orderDuLog('ORDER_STAY_TIME', {
        orderNo: orderNo.value,
        stayTime,
        type,
      })
    }
    stayOrderDetailTime.currentTime = nowTime
  }
  /** d：如果最近的路由是订单页面，则重置时间*/
  if (constant === current) {
    stayOrderDetailTime.currentTime = getNowTime()
  }
}

/** 监听路由 */
watch(
  () => {
    return { name: route.name, id: route.params?.id }
  },
  throttle(
    (currentRoute, lastRoute) => {
      /** 从工单出发：只用考虑上一个路由是订单页面的情况 */
      uplog(currentRoute?.name, lastRoute?.name, `${globalConfig.backstageCode}_orderdetail`, 'routeChange')
    },
    100,
    { leading: true, trailing: false }
  ),
  {
    deep: true,
    immediate: true,
  }
)

2.2. Nombre de rebonds de pages

Le nombre de rebonds de page est relativement simple. Il vous suffit d'ajouter une méthode de rapport de données au gestionnaire de l'événement de rebond, comme l'affichage des détails du produit, des détails de retour et d'échange, des informations de versement de l'utilisateur, des détails de l'ordre de travail, etc., et enfin calculer le nombre total de rebonds.

2.3. Résumé

Le temps de séjour moyen de l'ancienne version de la page est de 15,6 secondes et le temps de séjour moyen de la nouvelle version de la page est de 8,5 secondes. Le temps passé par le service client à chaque fois qu'il interroge des informations est raccourci de 7,1 secondes. La moyenne quotidienne peut être converti en fonction du PV de la page de détails, ce qui peut réduire les heures de travail des étudiants du service client .

Dans le même temps, le service client doit passer à une autre page lorsqu'il interroge des informations de commande spécifiques. Cela montre que les informations de commande sont manquantes ou que le service client a des doutes quant à l'exactitude des informations. Le taux de rebond de l'ancienne version de la page est de 11,4 % (environ 8,7 visites ont rebondi 1 fois), le taux de rebond de la nouvelle page est de 7,92 % (environ 1 rebond pour 12,6 visites). Le taux de rebond lorsque le service client vérifie les informations de commande a également chuté de 3,48 points de pourcentage .

6. Résumé et planification

1. Résumé

Concernant la réutilisation multiplateforme des pages de routage dynamique : utilisez la communication iframe à instance unique à travers les piles technologiques et utilisez les événements postMessage bidirectionnels pour surveiller le comportement des utilisateurs afin de déclencher des interactions ; utilisez la communication de fédération de modules au sein des micro-applications, qui garantit non seulement l'expérience du service client. , mais permet également de gagner du temps de développement et des coûts de maintenance.

• Le premier écran de MF prend 1279 ms et le deuxième écran ne prend que 428 ms . Le temps de rendu est réduit de 6 fois .
• L'utilisation de la mémoire d'une seule page est réduite à moins de 1/10 de la précédente .

Concernant l'optimisation du premier écran de la page avec un grand volume de données : sur la base du timing des appels d'interface d'optimisation métier, assurez-vous que pas plus de 6 requêtes d'interface sont effectuées en même temps pour éviter les blocages chronophages, optimisez la grande interface RT , si le scénario le permet, il peut être modifié en type de protocole GET pour réduire le temps de réponse du premier écran et améliorer l'expérience du service client.

• Lorsque le premier écran demande plus de 6 interfaces, le temps de blocage n'apparaîtra plus. Une fois la grande interface modifiée en GET, la consommation totale de temps est de 2/3 du POST .
• L'interface de détail rapide RT ne prend en moyenne que 190 ms , soit une baisse de 41 % par rapport aux 470 ms de la grande interface précédente . Le temps de rendu du premier écran est passé de 873 ms à 376 ms , soit une baisse de 57 % , et le 95e percentile était de 567 ms. , soit une baisse de 62% .

Concernant l'agencement des informations et le renforcement des capacités des modules d'extension : en fonction des caractéristiques des champs d'analyse commerciale, convenir des formats de schéma appropriés afin que le contenu des informations puisse être configuré de manière flexible ; analyser les caractéristiques fonctionnelles et les conditions d'équipement des utilisateurs afin que la présentation et le contenu des les pages visitées par les utilisateurs peuvent être différenciées afin que les utilisateurs puissent voir le contenu approprié et réduire l'effort des agents pour interroger les informations.

• Les coûts de développement de la demande de commande peuvent être réduits de 66,7 % .
• Le temps de séjour moyen de l'ancienne version de la page est de 15,6 s et le temps de séjour moyen de la nouvelle version de la page est de 8,5 s. Le temps passé par le service client à chaque fois qu'il interroge des informations est raccourci de 7,1 s . PV de la page de détails de la commande, on peut calculer que le temps d'interrogation quotidien des étudiants du service client peut être réduit .
• Le taux de rebond de l'ancienne version de la page est de 11,4 % (environ 1 rebond pour 8,7 visites) et le taux de rebond de la nouvelle version est de 7,92 % (environ 1 rebond pour 12,6 visites). Lorsque le service client a vérifié les informations de la commande, le taux de rebond a chuté de 3,48 pp .

2. Planification du suivi

Bien que l'expérience utilisateur de la page de détails des commandes du service client ait été améliorée, le chemin vers la mise à niveau de l'expérience se poursuit :

• Bien que la fédération de modules soit rapide, le coût de maintenance des dépendances publiques est élevé, ce qui entraînera également une diminution de la vitesse de construction des applications. À l'avenir, la sous-application de commande sera migrée sur la base d'Unbounded et un conteneur d'application sera construit spécifiquement pour stocker les composants distants. Cela améliorera le lancement instantané et l'expérience de commutation rapide de la sous-application. Cela augmentera également la vitesse de construction. de la sous-application d'ordre de travail et découpler la libération des fonctions d'ordre horizontal. J'attends avec impatience le contenu de suivi.

‍

*Texte/Changement

Cet article est original de Dewu Technology. Pour des articles plus intéressants, veuillez consulter : Site officiel de Dewu Technology

La réimpression sans l'autorisation de Dewu Technology est strictement interdite, sinon la responsabilité légale sera engagée conformément à la loi !

L'auteur du framework open source NanUI s'est tourné vers la vente d'acier et le projet a été suspendu. La première liste gratuite de l'App Store d'Apple est le logiciel pornographique TypeScript. Il vient de devenir populaire, pourquoi les grands commencent-ils à l'abandonner ? Liste TIOBE d'octobre : Java connaît la plus forte baisse, C# se rapproche de Java Rust 1.73.0 publié Un homme a été encouragé par sa petite amie IA à assassiner la reine d'Angleterre et a été condamné à neuf ans de prison Qt 6.6 officiellement publié Reuters : RISC-V la technologie devient la clé de la guerre technologique sino-américaine Nouveau champ de bataille RISC-V : non contrôlé par une seule entreprise ou un seul pays, Lenovo prévoit de lancer un PC Android

{{o.name}}

{{m.nom}}