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

站在用戶的角度思考問題，與客戶深入溝通，找到珠海網(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ū)。

一、前言

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

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

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

1. 困境

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

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

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

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

2. 融合開發(fā)

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

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

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

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

3. 著手解決

確定目錄架構(gòu)

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

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

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

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

工具鏈的選擇

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

pc.json 大致如下：

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

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

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

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

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

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

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

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

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

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

轉(zhuǎn)換成：

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

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

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

在 build 的過程中，由于要同時(shí)構(gòu)建出 PC 和 Mobile 的 demo，而 build-plugin-component 只能啟動 Rax 或者 React 其中一邊的構(gòu)建，顯然這無法滿足我們的需求，如果調(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 的編譯問題，由于源碼中包含了一部分 react 文件也包含了一部分 rax 文件，在 start 時(shí)還可以按照 entry 的依賴鏈來設(shè)置 babel 配置，但是 build 時(shí)對源文件只過 babel 沒有 webpack，所以要使用其他的辦法來處理。 我們采取的方式 是先分析每 個(gè)文件的 AST，從文件的包引用上分析出該文件是一個(gè) React 還是 Rax 組件，然后采用不同的 babel 配置來進(jìn)行編譯。 這里為什么沒有采用和上文提到的 demo 里的同樣的方式進(jìn)行處理呢？ 原因是 demo 的方式對 createElement 的引入是強(qiáng)依賴，寫法上比較受限，在源碼部分我們希望能夠讓用戶擁有更靈活的使用方式。

這樣基本上在 ProCode 下的場景都可以正常使用了，但樂高環(huán)境下還不行，主要還是處在 prototypeView.tsx 這個(gè)文件的處理上，上面我們提到過，這個(gè)文件會同時(shí)引入 React 和 Rax 組件，雖然在設(shè)計(jì)態(tài)，只會有其中一個(gè)組件被真正渲染出來，但有些 API 是在組件類的聲明時(shí)就會用到，例如 Rax.forwardRef。這就導(dǎo)致不做任何處理的情況下，在設(shè)計(jì)態(tài)會因?yàn)槿鄙?API 而報(bào)錯(cuò)無法使用。而樂高的組件保存構(gòu)建，和一般的 Procode 項(xiàng)目，是每個(gè)組件單獨(dú)構(gòu)建的，而組件在構(gòu)建時(shí)并不知道自己是要在樂高 PC（React 環(huán)境）還是樂高小程序（Rax 環(huán)境）里使用。所以我們在組件本地構(gòu)建時(shí)會額外生成一個(gè) prototypeView.rax.js，這個(gè)文件在內(nèi)容和構(gòu)建后的 prototypeView.js 并沒有本質(zhì)區(qū)別，但是提供給樂高打包構(gòu)建一個(gè)額外的入口，樂高構(gòu)建時(shí)探測到是一個(gè)融合包時(shí)對這兩個(gè)文件入口配置不同的 webpack alias，在 prototypeView.js 里會將 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ā)和使用過程，統(tǒng)一到了一個(gè)包（融合 vc 包），一個(gè)工具鏈（vdev：初始化、調(diào)試、發(fā)布），對 @ali/deep 和 @ali/deep-mobile 這兩個(gè)基礎(chǔ)組件包實(shí)現(xiàn)按需加載編譯（也支持 Fusion/Antd）。使用的時(shí)候，無論 PC 端、小程序還是可視化的部分，都可以引用同一個(gè)包，沒必要去記住不同的包名和他們對應(yīng)的平臺。正常情況下，我們可以通過直接引用包名來引入 PC 部分，通過 es/view.mobile（或者 lib/view.mobile） 引入移動端/小程序部分。另外，這里我們在 package.json 里將對應(yīng)的入口也做了注冊，這樣可以通過 webpack resolve 配置也可以實(shí)現(xiàn)通過包名就直接引用移動端部分的效果。

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

1  困境

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

2  自動生成 prototype.tsx

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

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

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

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

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

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

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

1  困境

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

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

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

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

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

3  實(shí)踐

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

ePaaS 的功能介

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

四  未來還有什么？

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

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

• 業(yè)務(wù)能力：能力是個(gè)比較虛的詞，在我這里的理解，他是一個(gè)以一個(gè)業(yè)務(wù)功能為核心的，不定數(shù)量個(gè)服務(wù)和UI（頁面、區(qū)塊、組件）的集合，帶服務(wù)的業(yè)務(wù)組件是我們在這個(gè)領(lǐng)域的第一步探索，接下來我們會把他繼續(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ū)動？：這個(gè)點(diǎn)打了一個(gè)問號，是因?yàn)槟壳斑€只是一個(gè)想法的階段。目前頁面在企業(yè)智能已經(jīng)實(shí)現(xiàn)了 ProCode、LowCode 和模型驅(qū)動三駕馬車的生產(chǎn)方式。業(yè)務(wù)組件方面已經(jīng)有了 ProCode 和 LowCode 的模式，那是否可以通過綁定模型的方式直接驅(qū)動 UI，通過配置生成業(yè)務(wù)組件，復(fù)用在業(yè)務(wù)里呢？這在一定程度上也可以解決現(xiàn)在能適用于模型驅(qū)動的標(biāo)準(zhǔn)頁面少的問題。

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

標(biāo)題名稱：怎么通過業(yè)務(wù)組件提效
標(biāo)題URL：http://jinyejixie.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)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)