本篇內(nèi)容介紹了“怎么通過(guò)業(yè)務(wù)組件提效”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

站在用戶的角度思考問(wèn)題，與客戶深入溝通，找到珠海網(wǎng)站設(shè)計(jì)與珠海網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：做網(wǎng)站、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名與空間、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋珠海地區(qū)。

一、前言

無(wú)論是在前端刀耕火種的 jQuery/YUI 時(shí)代，還是到現(xiàn)在基于數(shù)據(jù)驅(qū)動(dòng) UI 的 React/Vue 時(shí)代，物料/組件一直是前端永恒的話題?；诖罅恐貜?fù)邏輯的封裝可以很顯而易見地提升前端 UI 的構(gòu)建效率，簡(jiǎn)單而直接，因此無(wú)論技術(shù)棧如何變化，物料工作都是排在各個(gè)前端團(tuán)隊(duì)的首要位置解決。

在 2021 年的現(xiàn)在來(lái)看，基于 React/Rax 體系下的基礎(chǔ)組件體系已經(jīng)基本完善，既有螞蟻良好設(shè)計(jì)語(yǔ)言的 AntDesign[1]，也有集團(tuán)基于 DPL 快速定制的 Fusion[2] （阿里中后臺(tái) UI 解決方案，已開源） ，在基礎(chǔ)組件的層面功能日趨完善，各個(gè)業(yè)務(wù)團(tuán)隊(duì)之間在這個(gè)層面的低級(jí)重復(fù)建設(shè)也越來(lái)越少，這是非常好的結(jié)果。但在業(yè)務(wù)組件體系的構(gòu)建上，目前還呈現(xiàn)著百花齊放的局面，由于技術(shù)棧的不斷擴(kuò)充（可視化、小程序等），業(yè)務(wù)組件的開發(fā)上還存在著很多諸如工程體系混亂，開發(fā)鏈路不通的問(wèn)題。

來(lái)到企業(yè)智能的 5 年多的時(shí)間里，經(jīng)歷了團(tuán)隊(duì)物料體系從最初的 Arale/kuma，到基于 react-component 的 UXCore/SaltUI，再到現(xiàn)在全面與 Fusion 融合?；A(chǔ)層面的變動(dòng)也帶來(lái)了業(yè)務(wù)組件領(lǐng)域的工具鏈的不斷變化。

1. 困境

某天，同事 A 找到我，說(shuō) TA 的業(yè)務(wù)里需要構(gòu)建一個(gè)業(yè)務(wù)組件包，涵蓋了 PC 端，小程序和對(duì)應(yīng)的可視化組件，當(dāng)時(shí)我正在做一些關(guān)于前端業(yè)務(wù)能力構(gòu)建的相關(guān)工作，所以想來(lái)問(wèn)下我的建議。這個(gè)問(wèn)題看似是很簡(jiǎn)單，但實(shí)際分析下來(lái)卻發(fā)現(xiàn)有很多問(wèn)題。

首先，PC 的業(yè)務(wù)組件當(dāng)時(shí)是使用 飛冰[3]（iceworks，阿里 GUI 構(gòu)建工具） + deep 腳手架模板（deep 出自企業(yè)智能用戶體驗(yàn)團(tuán)隊(duì)）的方式來(lái)開發(fā)的，好處是 可以 和 Fus ion 深度打通，發(fā)布 和同步物料到 Fusion 對(duì)應(yīng)的 deep 站點(diǎn)都比較方便。小程序/移動(dòng)端的組件，當(dāng)時(shí)基于 Rax 的動(dòng)態(tài)化小程序組件方案 Fusion Mobile 和 Deep Mobile 剛剛起步，業(yè)務(wù)組件的開發(fā)還沒有自己的標(biāo)準(zhǔn)，唯一一套可用的是之前政務(wù)釘釘?shù)那岸藞F(tuán)隊(duì)做的 gdt-utils 來(lái)承載。

而可視化組件，則是由樂高 （ 阿里企業(yè)級(jí)可視化搭建平臺(tái) ） 團(tuán)隊(duì)提供的 vdev 工具鏈，而當(dāng)時(shí)還有一個(gè)問(wèn)題是，由于 PC 端基于 React 框架，而小程序/移動(dòng)端則基于 Rax 框架，導(dǎo)致可視化開發(fā)時(shí)也無(wú)法通過(guò)初始化一個(gè)包來(lái)完成 PC 和小程序端的開發(fā)。

總結(jié)起來(lái)，開發(fā)一個(gè)涵蓋三種模式的業(yè)務(wù)組件，需要適應(yīng)和學(xué)習(xí)三種工具鏈，初始化四個(gè)包，發(fā)布四個(gè) npm package，而后續(xù)使用中，使用者需要記住四個(gè)包名以及他們對(duì)應(yīng)的使用場(chǎng)景，和在至少兩個(gè)地方看他們的使用方法。同時(shí)在維護(hù)的階段，PC 和 移動(dòng)端相似的模型、請(qǐng)求、數(shù)據(jù)處理邏輯也無(wú)法得到復(fù)用，如果想要復(fù)用怎么辦？不好意思，那就需要再發(fā)一個(gè)工具包在幾個(gè)包之間做流轉(zhuǎn)。這些都在無(wú)形中增加了開發(fā)一個(gè)業(yè)務(wù)組件的成本，同學(xué)們的精力就在這些框架、包和聯(lián)調(diào)的過(guò)程中消耗掉了。

2. 融合開發(fā)

雖然從結(jié)果來(lái)看，這樣子可以完成開發(fā)，但從上手門檻和開發(fā)效率上來(lái)說(shuō)確實(shí)不如人意，一是需要寫大量的文檔來(lái)把這件事情說(shuō)清楚，二是僅僅為了開發(fā)一個(gè)業(yè)務(wù)組件，需要這么大的成本真的是一個(gè)好的方案嗎？那可不可以不要那么多東西，就一個(gè)工具鏈，一個(gè)包解決所有問(wèn)題，這樣不好嗎？好是好，但真要這么做之前，有很多問(wèn)題需要解決。

最大的問(wèn)題在于，如何將 Rax 和 React 兩種框架有機(jī)結(jié)合在一個(gè)工具鏈中。這看似是一個(gè)不怎么困難的問(wèn)題，貌似是只要把以前的 React 和 Rax 的 webpack 配置拿過(guò)來(lái)各跑各的就行了，但融合之后有些東西是合成一份的，比如 demo 文件，對(duì)于一個(gè)希望融合開發(fā)的同學(xué)來(lái)說(shuō)，自然是不希望，寫幾份幾乎相同的 demo，僅僅是因?yàn)椴煌倪\(yùn)行框架帶來(lái)的引用不同。相似的還有可視化組件當(dāng)中的 prototypeView 文件，這個(gè)文件用于在樂高設(shè)計(jì)器中渲染組件，這里需要一點(diǎn)樂高組件開發(fā)的知識(shí)，prototypeView 文件的大致代碼組成是這樣的：

這樣的設(shè)計(jì)是在可視化組件都是 React 框架的前提下設(shè)計(jì)出來(lái)的，在以往的實(shí)踐中是沒有問(wèn)題的。

但融合開發(fā)后，就像上面代碼中的注釋一樣，如何驅(qū)動(dòng)一個(gè) React 組件和一個(gè) Rax 組件混合打包，并且可以正常渲染，需要有解決的辦法。 其次，從工程的角度，選取哪個(gè)工具鏈來(lái)實(shí)現(xiàn)這個(gè)融合開發(fā)的能力？ 顯然目前的每條工具鏈都不具備直接實(shí)現(xiàn)的能力，那是選取其中某一個(gè)進(jìn)行增強(qiáng)，還是另起爐灶結(jié)合三者的能力？ 各有利弊，需要權(quán)衡。 還有一個(gè)必須考慮的點(diǎn)，就是如何盡量減少對(duì)開發(fā)者原有心智的改變，以及盡量保持對(duì) Fusion 物料能力的匹配（如同步到 Fusion 站點(diǎn)），這樣才可以讓開發(fā)者以盡量少的代價(jià)遷移到新的開發(fā)模式上來(lái)。 確認(rèn)了這些問(wèn)題之后，我們開始著手通過(guò) 融合 開發(fā)來(lái)解決這個(gè)開發(fā)困境。

3. 著手解決

確定目錄架構(gòu)

首先我們需要確定融合開發(fā)包（后簡(jiǎn)稱“融合包”）的目錄結(jié)構(gòu)：

從源碼結(jié)構(gòu)上，我們基本沿用了可視化組件的文件結(jié)構(gòu)，這樣一方面滿足了可視化組件特殊的要求（如設(shè)置器的配置，設(shè)計(jì)態(tài)的渲染等），另一方面通過(guò)制定 package.json 的 main 字段，也可以實(shí)現(xiàn)直接引用包名調(diào)用組件的需求。

而技術(shù)棧上則全面使用 ts 和 scss，和 Fusion 組件對(duì)齊，同時(shí)方便使用 scss 變量和 css 變量。

在構(gòu)建產(chǎn)物上，我們則結(jié)合了幾個(gè)工具鏈產(chǎn)物的特點(diǎn)，首先構(gòu)建 babel 轉(zhuǎn)譯過(guò)的 es5 文件和對(duì)應(yīng)的聲明文件，用于一般項(xiàng)目中。其次構(gòu)建保留的 import/export 的 esmodule，用于對(duì)包體積有要求的項(xiàng)目做 treeShaking。而后，將對(duì)應(yīng)的 md 構(gòu)建成可直接瀏覽器預(yù)覽的 demo 放在 build 文件夾中與 Fusion 組件對(duì)齊，再將 lib 文件夾下的文件復(fù)制到 build 目錄中，方便樂高構(gòu)建和識(shí)別（樂高構(gòu)建的時(shí)候會(huì)直接去找 build 目錄下的 view.js 和 view.mobile.js 等文件）。

工具鏈的選擇

在工具鏈的選擇上，我們最終選擇了樂高的開發(fā)套件 vdev 作為底座進(jìn)行擴(kuò)展，這樣做的考慮是可視化組件的整套開發(fā)體系較重，且未插件化，抽取遷移的成本較高。其次，相比其他兩套工具鏈，vdev 在大團(tuán)隊(duì)的基礎(chǔ)架構(gòu)部門維護(hù)，溝通協(xié)作相對(duì)簡(jiǎn)單。剩余的部分我們并沒有完全重造，而是盡可能地復(fù)用起現(xiàn)有的 build-scripts 體系下的插件。我們首先對(duì) vdev 進(jìn)行了改造，支持了 build-scripts 相關(guān)體系的調(diào)用，剩余的開發(fā)則基于 build-scripts 下的 plugin 開始開發(fā)，最終的大致鏈路如下：

pc.json 大致如下：

在開發(fā)的時(shí)候我們定下了一個(gè)原則，基于通用規(guī)則下的 PC、Mobile 和小程序預(yù)覽，我們盡量通過(guò)官方的 build-plugin-component 來(lái)實(shí)現(xiàn)，不支持的功能或 bug 通過(guò)共建補(bǔ)齊或修復(fù)，而針對(duì)融合包的特殊規(guī)則，如融合需要的特殊配置處理，構(gòu)建后的文件轉(zhuǎn)移等邏輯，通過(guò) build-scripts 體系下后序插件（我們這里命名為 build-plugin-vdev-component）可以對(duì)前序插件定義的配置做進(jìn)一步處理的特性來(lái)增加。這樣既減小了后續(xù)的維護(hù)成本，又可以通過(guò) build-plugin-component 幫助到更多的業(yè)務(wù)。

確定好基礎(chǔ)的架構(gòu)之后，我進(jìn)一步定義了融合包相關(guān)的 npm scripts：

• start：用于啟動(dòng)可視化部分的調(diào)試，包含設(shè)計(jì)器和預(yù)覽

• startPC：用于啟動(dòng) PC 部分的調(diào)試

• startMobile：用于啟動(dòng)移動(dòng)端 Web 部分的調(diào)試

• startMiniapp：用于啟動(dòng)移動(dòng)端小程序部分的調(diào)試

• build：用于生成上文提到的構(gòu)建產(chǎn)物

其中除 start 外，其他都依靠 build-scirpts 插件體系來(lái)完成。

調(diào)試主要解決的問(wèn)題

大致框架都確定后，就要開始具體的開發(fā)流程。start 相關(guān)的流程需要修改的不多，主要是把組件名 alias 到對(duì)應(yīng)的入口（PC 到 view.tsx, Mobile 到 view.mobile.tsx），剩下的主要是補(bǔ)全 build-plugin-component 中缺失的功能，比如 Rax 部分里對(duì) scss 的支持，inlineStyle 配置的支持。有個(gè)值得稍微提一下的點(diǎn)是關(guān)于對(duì) demo 文件中 jsx 的處理。我們都知道 jsx 是 React 提出的 js 的加強(qiáng)型語(yǔ)法，用于將模板可以完全使用 js 語(yǔ)法來(lái)描述，實(shí)際在瀏覽器是不能直接識(shí)別的，一般的處理方式是通過(guò) babel 轉(zhuǎn)換成對(duì)應(yīng)的轉(zhuǎn)換語(yǔ)法，如把

轉(zhuǎn)換成：

對(duì)于的 jsx 標(biāo)簽如 <div> 會(huì)被轉(zhuǎn)換成 React.createElement("div") 。這在單一框架下是沒有問(wèn)題的，但由于融合包中 demo 是在 PC 和 移動(dòng)端復(fù)用的，那這里是轉(zhuǎn)換成 React.createElement 還是 Rax.createElement 呢？顯然都不太合適，他只有在具體啟動(dòng)調(diào)試 PC 還是小程序時(shí)才能決定，而且 Rax 官方其實(shí)更推薦的寫法是不要直接引用全量的 Rax 變量，而是從 Rax 變量中按需加載對(duì)應(yīng)的 api，如 createElement，寫法上天然有區(qū)別。所以我們?cè)?demo 文件的寫法上取了一個(gè)交集，大致如下：

demo 文件的寫法上是基于 PC 的視角的，引用的依賴是 react 的 Component 和 createElement，以及基礎(chǔ)組件庫(kù) @ali/deep。在啟動(dòng)小程序調(diào)試時(shí)，react alias 到 rax ，@ali/deep alias 到 @ali/deep-mobile。而 jsx 相關(guān)的，如 <div> 會(huì)被轉(zhuǎn)換成 createElement("div") ，這樣從寫法上保證了編譯后的可行性。

構(gòu)建主要解決的問(wèn)題

在 build 的過(guò)程中，由于要同時(shí)構(gòu)建出 PC 和 Mobile 的 demo，而 build-plugin-component 只能啟動(dòng) Rax 或者 React 其中一邊的構(gòu)建，顯然這無(wú)法滿足我們的需求，如果調(diào)用兩次腳本，中間又存在著大量的重復(fù)操作，如文件夾的新增和刪除等等。 我們選擇的是使用 build-plugin-component 的 rax 部分，并在后序插件 build-plugin-vdev-component 里另起一個(gè) React 的 webpa ck task，同時(shí)完成 PC 和 Mobile 的 demo 構(gòu)建。

在構(gòu)建 es5 的文件時(shí)，也遇到了 jsx 的編譯問(wèn)題，由于源碼中包含了一部分 react 文件也包含了一部分 rax 文件，在 start 時(shí)還可以按照 entry 的依賴鏈來(lái)設(shè)置 babel 配置，但是 build 時(shí)對(duì)源文件只過(guò) babel 沒有 webpack，所以要使用其他的辦法來(lái)處理。 我們采取的方式 是先分析每 個(gè)文件的 AST，從文件的包引用上分析出該文件是一個(gè) React 還是 Rax 組件，然后采用不同的 babel 配置來(lái)進(jìn)行編譯。 這里為什么沒有采用和上文提到的 demo 里的同樣的方式進(jìn)行處理呢？ 原因是 demo 的方式對(duì) createElement 的引入是強(qiáng)依賴，寫法上比較受限，在源碼部分我們希望能夠讓用戶擁有更靈活的使用方式。

這樣基本上在 ProCode 下的場(chǎng)景都可以正常使用了，但樂高環(huán)境下還不行，主要還是處在 prototypeView.tsx 這個(gè)文件的處理上，上面我們提到過(guò)，這個(gè)文件會(huì)同時(shí)引入 React 和 Rax 組件，雖然在設(shè)計(jì)態(tài)，只會(huì)有其中一個(gè)組件被真正渲染出來(lái)，但有些 API 是在組件類的聲明時(shí)就會(huì)用到，例如 Rax.forwardRef。這就導(dǎo)致不做任何處理的情況下，在設(shè)計(jì)態(tài)會(huì)因?yàn)槿鄙?API 而報(bào)錯(cuò)無(wú)法使用。而樂高的組件保存構(gòu)建，和一般的 Procode 項(xiàng)目，是每個(gè)組件單獨(dú)構(gòu)建的，而組件在構(gòu)建時(shí)并不知道自己是要在樂高 PC（React 環(huán)境）還是樂高小程序（Rax 環(huán)境）里使用。所以我們?cè)诮M件本地構(gòu)建時(shí)會(huì)額外生成一個(gè) prototypeView.rax.js，這個(gè)文件在內(nèi)容和構(gòu)建后的 prototypeView.js 并沒有本質(zhì)區(qū)別，但是提供給樂高打包構(gòu)建一個(gè)額外的入口，樂高構(gòu)建時(shí)探測(cè)到是一個(gè)融合包時(shí)對(duì)這兩個(gè)文件入口配置不同的 webpack alias，在 prototypeView.js 里會(huì)將 rax 相關(guān)的 api alias 到 remaxjs 社區(qū)的 rax-compact 包上，用于樂高 PC 版設(shè)計(jì)態(tài)的展示（React 環(huán)境）。在 prototypeView.rax.js 中將 react 相關(guān)的 api alias 到 rax/lib/compact 上，用于樂高小程序設(shè)計(jì)態(tài)的展示（Rax 環(huán)境）。

4. 最終效果

最終我們將業(yè)務(wù)組件的開發(fā)和使用過(guò)程，統(tǒng)一到了一個(gè)包（融合 vc 包），一個(gè)工具鏈（vdev：初始化、調(diào)試、發(fā)布），對(duì) @ali/deep 和 @ali/deep-mobile 這兩個(gè)基礎(chǔ)組件包實(shí)現(xiàn)按需加載編譯（也支持 Fusion/Antd）。使用的時(shí)候，無(wú)論 PC 端、小程序還是可視化的部分，都可以引用同一個(gè)包，沒必要去記住不同的包名和他們對(duì)應(yīng)的平臺(tái)。正常情況下，我們可以通過(guò)直接引用包名來(lái)引入 PC 部分，通過(guò) es/view.mobile（或者 lib/view.mobile） 引入移動(dòng)端/小程序部分。另外，這里我們?cè)?package.json 里將對(duì)應(yīng)的入口也做了注冊(cè)，這樣可以通過(guò) webpack resolve 配置也可以實(shí)現(xiàn)通過(guò)包名就直接引用移動(dòng)端部分的效果。

二  重復(fù)的過(guò)程是否可以不做？

1  困境

融合開發(fā)的第一個(gè)版本，解決了開發(fā)者在項(xiàng)目工程維護(hù)、發(fā)布和使用者使用包時(shí)的耗費(fèi)心智的問(wèn)題，同時(shí)對(duì)于在 PC 和 Mobile 復(fù)用邏輯上有較大幫助。但開發(fā)者在開發(fā)過(guò)程中仍有很多重復(fù)勞動(dòng)的過(guò)程。比如雖然已經(jīng)有了完整的 ts 支持和接口聲明，但是用戶還是需要自己配置組件的 setter，配置 setter 組件的過(guò)程主要是指定 setter 對(duì)應(yīng)的屬性，默認(rèn)值和類型。比如組件發(fā)布之后，還需要通過(guò)一套入駐機(jī)制，才能在物料中心給自己和他人查看 Demo。比如小程序調(diào)試，每次本地啟動(dòng)構(gòu)建后，還要打開小程序的 IDE。這些都是每個(gè)業(yè)務(wù)組件開發(fā)中不得不做，但基本重復(fù)的工作，凡是重復(fù)的事情都是有規(guī)律可言，這些重復(fù)的事情能否不做？

2  自動(dòng)生成 prototype.tsx

前面也提到融合開發(fā)包里面 PC 和 Mobile 的開發(fā)入口文件已經(jīng)全面 ts 化和模板化了，入口文件大致如下（這里展示的是 PC 入口 view.tsx， Mobile 與此類似）：

通過(guò) AST 分析，我們可以定位到所有的 interface 聲明以及 defaultProps 聲明。typescript lint 中要求一個(gè)文件中只有一個(gè) Class 聲明，再加上 Component 的 ts 泛型，這些前提條件讓我們可以定位到 props 的接口，從而得到每個(gè) prop 的 name 和類型。考慮到業(yè)務(wù)組件的最重要目的是能夠快速在樂高里使用起來(lái)，所以我們沒有必要對(duì)每種類型和默認(rèn)值做特別精細(xì)化的映射，我們可以為基礎(chǔ)類型找到對(duì)應(yīng)的 setter，對(duì)一些復(fù)雜的類型指定為一個(gè) JSONSetter，對(duì)渲染函數(shù)鉤子指定為 ActionSetter，對(duì)回調(diào)事件指定為 events。prototype.tsx 的模板文件也是一個(gè)比較標(biāo)準(zhǔn)的寫法，因此我們可以比較方便地通過(guò) AST 分析出已經(jīng)定義過(guò)的屬性，這些屬性不需要再增加一遍，以及插入新屬性代碼的位置，通過(guò)直接生成這部分設(shè)置器代碼，我們的組件基本上可以在不需要修改的情況下在設(shè)計(jì)器里正常使用起來(lái)（指可以配置各個(gè)屬性，流暢地使用組件的各個(gè)功能，而非僅是展示）。

3  發(fā)布自動(dòng)同步物料中心

組件發(fā)布只是第一步，一個(gè)業(yè)務(wù)組件只有能夠被發(fā)現(xiàn)，文檔可以被閱讀，才是組件服務(wù)的開始。在企業(yè)智能，我們目前統(tǒng)一使用物料中心進(jìn)行組件的展示。過(guò)去的業(yè)務(wù)組件只能通過(guò)物料中心后臺(tái)配置的方式才能上架到物料中心，這個(gè)過(guò)程需要大量的手動(dòng)填寫的東西，耗時(shí)耗力。這部分我們也做了優(yōu)化，在組件發(fā)布到 tnpm 后，vdev 來(lái)收集上架必要的信息，如組件 owner，組件分屬業(yè)務(wù)領(lǐng)域，組件適配的端等等，物料中心提供 API 調(diào)用，直接將這些信息同步至物料中心，實(shí)現(xiàn)一鍵發(fā)布+上架物料中心的效果。當(dāng)然，這個(gè)同步并非強(qiáng)制，對(duì)于一些測(cè)試版，可以選擇不進(jìn)行同步。

4  小程序 WebIDE 調(diào)試

原有小程序調(diào)試必須要在本地構(gòu)建出一個(gè)符合小程序結(jié)構(gòu)的項(xiàng)目目錄，然后再使用小程序 IDE 打開對(duì)應(yīng)目錄才能開始調(diào)試，這個(gè)過(guò)程跨越多個(gè)工具鏈，學(xué)習(xí)成本和操作成本都比較高。恰好支付寶小程序團(tuán)隊(duì)推出了 @ali/mini 工具鏈，可以基于項(xiàng)目目錄下一鍵啟動(dòng) Lyra 瀏覽器模擬器進(jìn)行調(diào)試。我們?nèi)诤祥_發(fā)包也對(duì) @ali/mini 做了集成，@ali/mini 需要的配置文件自動(dòng)幫助組件開發(fā)者生成，通過(guò)一個(gè)命令就可以直接啟動(dòng) WebIDE 進(jìn)行調(diào)試了。

三  如何簡(jiǎn)單地開發(fā)/使用一個(gè)帶服務(wù)的組件？

1  困境

上面兩部分，我們主要圍繞的是一個(gè)純 UI 的業(yè)務(wù)組件開發(fā)，但我們也知道很多業(yè)務(wù)模塊都是需要配合后端服務(wù)一起使用才能完整表達(dá)一個(gè)場(chǎng)景，最簡(jiǎn)單的例子就是一個(gè)搜人組件，不搭配服務(wù)就是一個(gè)列表樣式有點(diǎn)特殊的選擇組件。

對(duì)于這類組件，以前有兩種策略，一是搭配一個(gè)跨域的 jsonp 接口，但隨著目前安全越來(lái)越收緊的情況下，這類接口越來(lái)越少了。另一個(gè)就是搭配一個(gè)業(yè)務(wù)上的接口，但這類接口和組件聯(lián)調(diào)非常麻煩，因?yàn)榻涌谥挥性趯?duì)于的業(yè)務(wù)域名下才能使用，因?yàn)檫@個(gè)限制條件，就分出了兩種不同的思路，一個(gè)是要在業(yè)務(wù)域上做個(gè)頁(yè)面出來(lái)或者干脆直接在業(yè)務(wù)項(xiàng)目里去調(diào)，更有甚者，前端直接把后端服務(wù)起起來(lái)本地調(diào)，想想都感覺很麻煩，新接手的同學(xué)估計(jì)光搭個(gè)環(huán)境就要花很長(zhǎng)的時(shí)間。

另一個(gè)策略就是前端使用 mock 的接口或者數(shù)據(jù)進(jìn)行調(diào)試，這類環(huán)境上相對(duì)簡(jiǎn)單一點(diǎn)，但帶來(lái)很大的聯(lián)調(diào)成本，首先 mock 接口有時(shí)很難模擬線上真實(shí)數(shù)據(jù)，其次誰(shuí)去一直維護(hù)這個(gè)接口一直和線上保持一致，帶來(lái)了額外的工作量。開發(fā)不方便，使用也不方便，由于接口是業(yè)務(wù)自己的，導(dǎo)致本地或者樂高里啟動(dòng)調(diào)試的時(shí)候，接口無(wú)法調(diào)通，只能花力氣部署到業(yè)務(wù)頁(yè)面上才能使用起來(lái)看效果?；蛘呤沁x擇組件里不默認(rèn)攜帶服務(wù)，真正使用的時(shí)候再去配對(duì)應(yīng)的接口，就出現(xiàn)了拿著組件去找接口的情況，接口本身有很多種形式，能 run 起來(lái)的方式也不一樣，能真正用起來(lái)看效果，也要花一段時(shí)間。

2  服務(wù)調(diào)用

上面的分析中可以看出，這類組件的主要難點(diǎn)在于服務(wù)的調(diào)用上，在沒有跨域請(qǐng)求接口的情況下，本地開發(fā)舉步維艱。所以核心問(wèn)題在于提供一類服務(wù)，可以方便地在本地或者樂高環(huán)境調(diào)用，同時(shí)不用擔(dān)心安全問(wèn)題（數(shù)據(jù)泄露和服務(wù)提供方壓力等），這就需要一個(gè) API 網(wǎng)關(guān)來(lái)，這個(gè)網(wǎng)關(guān)可以解決服務(wù)調(diào)用的鑒權(quán)，以及對(duì)服務(wù)提供方進(jìn)行保護(hù)。有了網(wǎng)關(guān)的情況下，下一步要解決的本地和樂高如何調(diào)用的問(wèn)題，樂高調(diào)用相對(duì)來(lái)說(shuō)比較簡(jiǎn)單，樂高本身是有后端服務(wù)的，只需要提供一個(gè)過(guò)程，在用戶接入某個(gè)組件和服務(wù)的時(shí)候，到網(wǎng)關(guān)去自動(dòng)申請(qǐng)日常服務(wù)的調(diào)用，由于日常服務(wù)大多已做了數(shù)據(jù)脫敏，且與真實(shí)數(shù)據(jù)隔離不能直接用于生產(chǎn)，所以日常服務(wù)的訂閱申請(qǐng)和審批都是相對(duì)比較簡(jiǎn)單的，這個(gè)過(guò)程可以在開通組件的背后直接完成。本地調(diào)用則相對(duì)會(huì)比較麻煩，一般本地調(diào)試都是 node 起一個(gè)本地 server（如 webpack dev server 等），背后很難直接完成接口的調(diào)用。這里有兩種解決思路，一個(gè)是服務(wù)端提供一個(gè)日常的跨域調(diào)用的轉(zhuǎn)發(fā)接口，用于轉(zhuǎn)發(fā)網(wǎng)關(guān)服務(wù)，如 /api/gateway?id=epaas.api.key，另一個(gè)則是服務(wù)端提供一個(gè)模板頁(yè)面，前端 server 提供 js 和 css，并注入到對(duì)應(yīng)的頁(yè)面中，這樣直接請(qǐng)求對(duì)應(yīng)的接口即可。

3  實(shí)踐

在 EI 的實(shí)踐中，恰好有這樣一個(gè)業(yè)務(wù)網(wǎng)關(guān) ePaaS 來(lái)承載網(wǎng)關(guān)的職責(zé)，在樂高的使用側(cè)，我們?cè)O(shè)計(jì)了一個(gè)業(yè)務(wù)能力模塊來(lái)做對(duì)應(yīng)的組件和服務(wù)開通，ePaaS 是通過(guò)應(yīng)用間的服務(wù)訂閱來(lái)實(shí)現(xiàn)跨業(yè)務(wù)調(diào)用的，所以我們?cè)陂_通業(yè)務(wù)能力前會(huì)先讓用戶填寫自己的 ePaaS，其實(shí)樂高預(yù)覽時(shí)這些是不需要的，讓用戶填寫是為了幫助用戶一鍵完成自己 ePaaS 這些接口的訂閱，而不需要用戶再自己去 ePaaS 上一個(gè)個(gè)手動(dòng)訂閱了。

ePaaS 的功能介

當(dāng)然 ePaaS 網(wǎng)關(guān)不是最終唯一的選擇，我們也在積極拓展其他網(wǎng)關(guān)的接入。

四  未來(lái)還有什么？

• 構(gòu)建效率提效：上面做的事情只是做到能，但還遠(yuǎn)稱不上好，尤其是經(jīng)常啟動(dòng)的調(diào)試命令，還有巨大的優(yōu)化空間，每個(gè)人每次節(jié)省 10s，加起來(lái)也是好多時(shí)間。

• 深入業(yè)務(wù)：目前在企業(yè)智能的一些業(yè)務(wù)域下已經(jīng)鋪開，但還沒有完全覆蓋，這套東西是從業(yè)務(wù)里來(lái)的，所以也應(yīng)該回到業(yè)務(wù)里去，業(yè)務(wù)的邊界場(chǎng)景會(huì)帶領(lǐng)我們逐漸進(jìn)入深水區(qū)。

• 業(yè)務(wù)能力：能力是個(gè)比較虛的詞，在我這里的理解，他是一個(gè)以一個(gè)業(yè)務(wù)功能為核心的，不定數(shù)量個(gè)服務(wù)和UI（頁(yè)面、區(qū)塊、組件）的集合，帶服務(wù)的業(yè)務(wù)組件是我們?cè)谶@個(gè)領(lǐng)域的第一步探索，接下來(lái)我們會(huì)把他繼續(xù)做深入，包括業(yè)務(wù)能力的樂高入駐，業(yè)務(wù)能力的本地生產(chǎn)等等。

• LowCode：目前樂高已經(jīng)具備了低代碼拖拽生成業(yè)務(wù)組件的能力，但只能在低代碼可視化的設(shè)計(jì)器里使用，而理想狀態(tài)下應(yīng)該是可以在各種狀態(tài)下流通，但是否是業(yè)務(wù)上的痛點(diǎn)，這個(gè)還在收集中。

• 模型驅(qū)動(dòng)？：這個(gè)點(diǎn)打了一個(gè)問(wèn)號(hào)，是因?yàn)槟壳斑€只是一個(gè)想法的階段。目前頁(yè)面在企業(yè)智能已經(jīng)實(shí)現(xiàn)了 ProCode、LowCode 和模型驅(qū)動(dòng)三駕馬車的生產(chǎn)方式。業(yè)務(wù)組件方面已經(jīng)有了 ProCode 和 LowCode 的模式，那是否可以通過(guò)綁定模型的方式直接驅(qū)動(dòng) UI，通過(guò)配置生成業(yè)務(wù)組件，復(fù)用在業(yè)務(wù)里呢？這在一定程度上也可以解決現(xiàn)在能適用于模型驅(qū)動(dòng)的標(biāo)準(zhǔn)頁(yè)面少的問(wèn)題。

“怎么通過(guò)業(yè)務(wù)組件提效”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

標(biāo)題名稱：怎么通過(guò)業(yè)務(wù)組件提效
標(biāo)題URL：http://aaarwkj.com/article0/jjjcoo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、做網(wǎng)站、網(wǎng)站設(shè)計(jì)、網(wǎng)站設(shè)計(jì)公司、網(wǎng)站排名、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)