关于前端:NutUI-3-开启-BCRM-商机新征程

22次阅读

共计 7030 个字符，预计需要花费 18 分钟才能阅读完成。

高铁的一直提速、5G 时代的到来、无人超市新兴我的项目的落地 …… 都在一直地揭示着咱们，要快、要高性能。那么作为程序员的咱们，该如何利用现有技术打造高性能产品，为用户带来“飞”个别的体验呢？

挑战“进行时”

BCRM 是企业业务重要的客户信息管理平台，承载现有客户入驻前权利治理全流程工作。商机板块为获客及拓客的重要板块，然而因为目前 BCRM 仅能 PC 内网拜访，如销售经理外出访问客户，很难第一工夫获取商机信息并保护分割记录信息，易造成商机信息散失及信息确认，为了进步商机的转化及跟进效率，决定接入京 ME 服务，进步销售应用效率。

7 月 28 号提需，打算在 8 月 10 号上线，在仅有的 10 个工作日内，需实现动态开发、联调、测试、上线，并且前端动态开发评估就有 17 集体 / 日，要在如此缓和的工夫里实现从 0 到 1 的高性能我的项目建设，咱们两个压力着实不小 ☹。

通过一番热烈的探讨后，咱们决定扭转既往的开发模式，在几个方面大胆翻新以应答即将来临的暴风雨：首先咱们想到的是合作模式，咱们要尽可能在最短的工夫内实现开发，就要让原本串行的工作并行起来；另外，怯懦尝试前端新兴技术，充分利用技术的力量为我的项目提供源源不断的能源；最初，在我的项目开发中，咱们深刻开掘，在疾速实现需要的根底上也能保障利用的飞速运行。

上面咱们就来详细描述一下吧👇！

“并行”合作

先来回忆一下咱们的日常开发流程：产品提需 -> 进行需要评审 -> 各方评估工时 -> 确定里程碑 -> 开发 -> 联调 -> 测试 -> 上线

日常迭代需要依照这个流程进行丝毫没故障，但如果利用到开发工夫如此缓和的 BCRM 中就有些来不及了。毕竟不是所有事件都必须是串行的，为什么不能将这些事件“并行”，节省时间呢？再加上每个人正式进入开发的工夫不统一，就会造成有的模块先开发完，有的稍晚一些，所以咱们最终决定开发、联调、测试同步进行，其中，先开发完的，优先提测。

当然，在人力资源正当的状况下，光是调整合作流程是不够的，要想从根本上进步开发效率、晋升利用性能，还得须要一个“新”的技术架构，毕竟大家都不想加班。

新技术带来新速度

BCRM 作为一个全新的我的项目，不存在兼容历史版本等问题，咱们能够大胆地采纳全新的技术栈进行开发。首先闯入脑海的就是最热门的 Vue3 + Vite + TypeScript 组合包，再加上最强辅助 NutUI3 作为组件库，何愁咱们的我的项目“飞”不起来。

高性能的 Vue3

Vue3 自公布以来，业内对其褒贬不一。与 Vue2 相比，有了很大的变动，由 Vue2 转为 Vue3 尽管须要肯定的学习老本的，但不得不抵赖的是 Vue3 比 Vue2 在性能方面有更杰出的体现。

在 Vue2 当中，当数据发生变化，它就会新生成一个 DOM 树，并和之前的 DOM 树进行比拟，找到不同的节点而后更新。但这比拟的过程是全量的比拟，也就是每个节点都会彼此比拟。但其中很显然的是，有些节点中的内容是不会产生扭转的，那咱们对其进行比拟就必定耗费了工夫。

<div>
    <p>BCRM 销售助手 </p>
    <p>{{msg}}</p>
</div>

所以在 Vue3 当中，就对这部分内容进行了优化：在创立虚构 DOM 树的时候，会依据 DOM 中的内容会不会发生变化，增加一个 PatchFlag，如果内容会变，就会标记一个 flag。那么之后在与上次虚构节点进行比照的时候，就只会比照这些带有 flag 的节点，缩小动态标记遍历老本。

除此以外，在 Vue2 中无论元素是否参加更新，每次都会从新创立，而后再渲染，白白浪费了不少性能。还是以方才的代码块为例，msg 每次更新都会创立后面的 p 节点。

import {createVNode as _createVNode, toDisplayString as _toDisplayString, openBlock as _openBlock,  createBlock as _createBlock} from "vue";

export function render(_ctx, _cache, $props, $setup, $data, $options) {return (_openBlock(), _createBlock("div", null, [_createVNode("p", null, "BCRM 销售助手"),
    _createVNode("p", null, _toDisplayString(_ctx.msg), 1 /* TEXT */)
  ]))
}

而在 Vue3 中对于不参加更新点元素，会做动态晋升，只会被创立一次，在渲染时间接复用即可，缩小从新创立造成的开销。

import {createVNode as _createVNode, toDisplayString as _toDisplayString, openBlock as _openBlock, createBlock as _createBlock} from "vue";

const _hoisted_1 = /*#__PURE__*/_createVNode("p", null, "Hello World", -1 /* HOISTED */)

export function render(_ctx, _cache, $props, $setup, $data, $options) {return (_openBlock(), _createBlock("div", null, [
    _hoisted_1,
    _createVNode("p", null, _toDisplayString(_ctx.msg), 1 /* TEXT */)
  ]))
}

高效打包的 Vite

2021 新年伊始，尤大就在知乎问答 2021 前端新变动中回复：” 会有很多人摈弃 Webpack 开始用 Vite “。从 Grunt、Gulp，到 Webpack、Rollup、Snowpack 以及若干构建框架，Vite 的哪些个性能让尤大如此自信，咱们无妨来钻研钻研 👀。

Vite 一个由 Vue 作者开发的原生 ESM 驱动的 Web 开发构建工具，在开发环境下基于浏览器原生 ES imports 开发，在生产环境下基于 rollup 打包。最大的特点就是“快”。运行 Dev 命令后只做了两件事件，一是启动了一个用于承载资源服务的 service；二是应用 esbuild 预构建 npm 依赖包。之后就始终躺着，直到浏览器以 http 形式发来 ESM 标准的模块申请时，Vite 才开始「按需编译」被申请的模块。

当然，Vite 还有很多值得一提的性能优化👇

Vite 刚进去的时候，在掘金上看到这样一段话，很有感触，想分享给大家：Webpack 并不是标准答案，前端构建工具能够有一些新的玩法：

  • 「打包」不是目标，「运行」才是，2021 年了，可能交给浏览器做的事件就交给浏览器吧，做一个会偷懒的程序猿不好吗！
  • 一个灵便的框架，对作者而言可能意味着逐渐失控的开发量；对用户而言可能象征高学习老本，以及一直反复的相似空格好还是 tab 好的争执。那么，一套内置好各种业界「最佳实际」，没有太多定制空间的工具，某些状况下反而能晋升大家的效率👏

弱小的组件库 NutUI3

工欲善其事，必先利其器。一个优良的前端工程师，除了一直进步本人的能力外，还要懂得使用工具。一款适合的组件库，能节俭大量的开发工夫。

作为一个京东格调的轻量级挪动端 Vue 组件库，NutUI3 采纳了 Vite2.x + Vue3 + TypeScript 的架构，与跟 BCRM 利用的技术栈不约而同。Vue3 在 Vue2 的根底上做了那么多的性能优化，NutUI3 也紧跟业务需要做了以下优化：

  • 采纳组合式 API Composition 语法重构，构造清晰，性能模块化
  • 组件 emits 事件独自提取，加强代码可读性
  • 应用 Teleport 新个性重构挂载类组件
  • …

那么在 BCRM 中，NutUI3 为咱们助力了哪些内容呢！

  1. 按需引入，点对点服务

开发中，不可能用到组件库中所有组件，如果在我的项目中导入所有的组件，最终打包文件会很大，所以此刻就要用到 NutUI3 的按需加载能力了。

因为 NutUI3 应用的是 Vite 构建工具，而 Vite 自身曾经按需导入了组件库，因而咱们只需按需导入款式即可。按需导入款式也不简单，只须要应用 Vite 提供的按需加载插件 vite-plugin-style-import 就能够实现。

首先，装置插件 

npm install vite-plugin-style-import --save-dev

在 vite.config.ts 中增加配置 

import vue from '@vitejs/plugin-vue'
import styleImport from 'vite-plugin-style-import';
export default {
  plugins: [
    ... ...
    styleImport({
      libs: [
        {
          libraryName: '@nutui/nutui',
          libraryNameChangeCase: 'pascalCase',
          resolveStyle: (name) => {return `@nutui/nutui/dist/packages/${name}/index.scss`
          }
        }
      ],
    }),
  ]
};

配置实现当前，记得重新启动哟，否则会不失效。接下来，咱们就能够引入组件了 

import {Button} from "@nutui/nutui";

通过下面的代码段，不仅按需引入了 Button 组件，就连 Button 组件款式也按需引入了，不须要在独自引入款式，有没有很不便。

  1. 组件的利用

BCRM 我的项目中应用到了包含：Uploader、Datepicker、Infiniteloading、Popup 等 10+ 个组件，NutUI3 为我的项目的构建提供了微小的便当。

在这里不得不说褒扬一下 Calendar 组件，开发中波及到的工夫抉择、工夫区间抉择性能都能完满笼罩。不仅反对抉择单个工夫、工夫区间，还能设置工夫抉择区间、重置到指定日期，真的不要太好用。

NutUI3 中的 Calendar 组件岂但充沛满足了业务需要，并且在应用过程中遇到的小 bug，开发者也能及时进行批改，丝毫没影响开发进度。很难设想，如果不利用 NutUI3，本人开发 Calender 组件，我的项目该何时上线。

开源的 Vue3 挪动端组件库本就凤毛鳞角，NutUI3 又如此优良，岂有不必之理！

性能再晋升

性能晋升，技术圈经典的话题，也是让有数程序员头疼的话题，常常在我的项目上破费很多工夫做性能优化，但最初仍然没有达到预期成果。不过，在 BCRM 中依赖 Vue3 做的性能优化，成果还是很显著的。

在 BCRM 开发中，因为工夫紧、工作重，性能优化的优先级更是一降再降，这可能是大多数我的项目开发的通病。在邻近上线时，视觉感知让咱们将性能优化提上日程，进行了深度优化。

Promise.all 晋升渲染速度

晋升页面渲染速度的目标就是为了让网页‘Duang’的一下子加载进去，而不是旋转半天都出不来，个别超过 5 秒，用户好感度就会降落。

大家猜猜看，上面这个页面在首次加载时，须要申请多少个接口：

答案是 23 个。能看到的内容全副是由接口提供的，并且为了获取一个字段，须要调用不止一个接口。以商机阶段字段为例：

  • 依据商机 ID 获取商机详情，失去商机阶段 k 值，此值是一个数字，并不是想要展现的文字描述
  • 通过刚刚失去的 k 值，申请接口获取所对应的文字描述

商机起源也须要同样的操作。

  • 依据商机 ID 获取商机详情，失去商机起源 k 值
  • 通过刚刚失去的 k 值，申请接口获取所对应的文字描述

不难发现，获取了商机详情数据后，获取商机阶段文字描述与获取商机起源文字描述的过程是没有分割的。

与下面的状况一样，在这 23 个申请中，22 个接口申请之间是没有分割的，并不需要辨别前后程序。但 JS 是单线程的，同一时间只能做一件事，即便是能够同时执行的申请。这时 Promise.all 闪亮退场，合并没有分割的申请，将它们包装成一个新的 Promise 实例，并以数组的模式返回申请后果，以此来缩小页面渲染工夫。

query.getDetail({coSn: str}).then((res) => {
    state.detail = res as object;
    let asksMap = new Map();
    asksMap.set("projectInfo", query.getProjectByCoSn({ coSn: str}));
    asksMap.set("applyLabel", query.coApplyLabel({ coSn: str}));
    asksMap.set("coTrajectory",query.coTrajectory({ coSn: str, pageSize: 100}));

    ... ...

    asksMap.set("planList",planService.queryPage({coId: state.detail.id,pageNo: 1,pageSize: 50}));

    Promise.all([...asksMap.values()])
      .then((results) => {results.forEach((result, i) => {state[[...asksMap.keys()][i]] = result;
          });
        },
        () => {}
      )
      .catch((error) => {});
})

async/await 渲染速度再降级

通过下面的优化，页面渲染速度失去显著晋升，但在优化过程中 async/await 引起了咱们的留神。async/await 将 JavaScript 开发者从回调函数的窘境中解救出来，然而随着对 async/await 的高度应用，也诞生了新的 async/await 窘境。

进行 JavaScript 异步编程时，通常一个接一个写多条语句，并在每个函数调用前标注一个 await。因为大多数时候，一条语句并不依赖于其之前的那条语句，然而你还是必须期待之前的语句执行结束。先来看一下上面这段代码片段 

async function orderItems() {const items = await getCartItems()    // async call
   const noOfItems = items.length
   for(var i = 0; i < noOfItems; i++) {await sendRequest(items[i])    // async call
   }
 }

给这段代码搭配这样的业务场景，获取购物车中的商品，并且每个商品去进行订购。乍一看，这段代码没什么问题，然而却存在很大的隐患。

在 for 循环中，必须期待 sendRequest() 函数执行结束能力持续下一轮循环。事实上每个商品之间的解决并没有关系，不须要期待。心愿尽可能快地发送申请，而后期待所有这些申请响应结束。如果购物车中的商品数量是上千、上万，页面解体是必定逃不了的，一旦呈现，排查问题都会很吃力。

有些性能优化做完之后，并不一定对现状有所帮忙，也不肯定能遇到极其状况，但放弃代码的健壮性，领有一个良好的代码开发习惯，何乐而不为呢！

Vuex 与 Map 强强联合

商机阶段、商机起源等字段贯通整个 BCRM 商机我的项目，尽管是接口获取，但以我的项目维度来说却是动态的，这种状况在我的项目开发中最常见不过的。面对这样的状况，前端个别只在我的项目初始化时，申请一次接口，并利用 Vuex 存储为常量。

let result = await service.getDict({kind: `${type}`});
if (result) {
  let obj = result as any;
  store.commit(type, obj);
}

但接口返回的数据格式让咱们感到一丝麻烦 

obj = [{k:1,v:'提审'},
  {k:2,v:'提审中'},
]

就像下面大节中提到的，后端返回给前端的之后 k 值，若想晓得 k 值对应的 v，每次都要循环遍历 Vuex 中存储的对象，无形中减少了代码量，同样也减少了出错的几率。所以将失去的后果进行转换，应用 Map 模式存储。

let result = await service.getDict({kind: `${type}`});
if (result) {
  let obj = result as any;

  let target = new Map();
  obj.forEach((item: DataVal) => {target.set(item.k, item);
  });
  const key: {[props: string]: string } = {
    co_sources: "setManageSources",
    ......
  };
  store.commit(key[type], target);
}

通过这样的转换，应用就能够简化为 

const {state} = useStore(key);
const value = state.manageSources.get(k).v

是不是一下子清晰了很多。在量级小时，这样的代码优化尽管对性能产生的作用微不足道，但量级一旦上来，就会产生巨变。

总结

短时间从 0 到 1 实现一个我的项目的过程是苦楚的，但作为 NutUI3 开发成员之一，看到 BCRM 我的项目中的每个页面都有 NutUI3 的“身影”，不禁感到兴奋。

2021Q1 Vue3 正式公布，曾经有越来越多的开发者开始应用 Vue3 作为开发语言。NutUI3 紧扣新技术，在 2021Q2 公布基于 Vue3 的版本 NutUI3.0。目前光咱们小组外部曾经有 5 个我的项目应用 NutUI3 开发，团体外部累计有 10+ 个我的项目应用 NutUI3 开发并上线经营。充沛表明了 NutUI3 不论在组件覆盖率还是稳定性都日趋完善。欢送共建，期待 PR！

正文完
前端
发表至： 前端
2022-03-23
 0
关于前端:Vuejs中的axios请求
关于前端:React-Ant-Design-Upload-组件定制开发-ustomRequest-自定义上传
关于前端:前端开发的基础生产力素养后期不定期更新
关于前端:Wallys-2×24GHz-2x5GHz-MT7915-MT7975-support-openwrt