本篇內(nèi)容介紹了“怎么通過業(yè)務(wù)組件提效”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！
站在用戶的角度思考問題，與客戶深入溝通，找到珠海網(wǎng)站設(shè)計與珠海網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：做網(wǎng)站、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名與空間、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋珠海地區(qū)。
無論是在前端刀耕火種的 jQuery/YUI 時代，還是到現(xiàn)在基于數(shù)據(jù)驅(qū)動 UI 的 React/Vue 時代，物料/組件一直是前端永恒的話題?；诖罅恐貜?fù)邏輯的封裝可以很顯而易見地提升前端 UI 的構(gòu)建效率，簡單而直接，因此無論技術(shù)棧如何變化，物料工作都是排在各個前端團隊的首要位置解決。
在 2021 年的現(xiàn)在來看，基于 React/Rax 體系下的基礎(chǔ)組件體系已經(jīng)基本完善，既有螞蟻良好設(shè)計語言的 AntDesign[1]，也有集團基于 DPL 快速定制的 Fusion[2] （阿里中后臺 UI 解決方案，已開源） ，在基礎(chǔ)組件的層面功能日趨完善，各個業(yè)務(wù)團隊之間在這個層面的低級重復(fù)建設(shè)也越來越少，這是非常好的結(jié)果。但在業(yè)務(wù)組件體系的構(gòu)建上，目前還呈現(xiàn)著百花齊放的局面，由于技術(shù)棧的不斷擴充（可視化、小程序等），業(yè)務(wù)組件的開發(fā)上還存在著很多諸如工程體系混亂，開發(fā)鏈路不通的問題。
來到企業(yè)智能的 5 年多的時間里，經(jīng)歷了團隊物料體系從最初的 Arale/kuma，到基于 react-component 的 UXCore/SaltUI，再到現(xiàn)在全面與 Fusion 融合。基礎(chǔ)層面的變動也帶來了業(yè)務(wù)組件領(lǐng)域的工具鏈的不斷變化。
1. 困境
某天，同事 A 找到我，說 TA 的業(yè)務(wù)里需要構(gòu)建一個業(yè)務(wù)組件包，涵蓋了 PC 端，小程序和對應(yīng)的可視化組件，當(dāng)時我正在做一些關(guān)于前端業(yè)務(wù)能力構(gòu)建的相關(guān)工作，所以想來問下我的建議。這個問題看似是很簡單，但實際分析下來卻發(fā)現(xiàn)有很多問題。
首先，PC 的業(yè)務(wù)組件當(dāng)時是使用 飛冰[3]（iceworks，阿里 GUI 構(gòu)建工具） + deep 腳手架模板（deep 出自企業(yè)智能用戶體驗團隊）的方式來開發(fā)的，好處是 可以 和 Fus ion 深度打通，發(fā)布 和同步物料到 Fusion 對應(yīng)的 deep 站點都比較方便。小程序/移動端的組件，當(dāng)時基于 Rax 的動態(tài)化小程序組件方案 Fusion Mobile 和 Deep Mobile 剛剛起步，業(yè)務(wù)組件的開發(fā)還沒有自己的標(biāo)準(zhǔn)，唯一一套可用的是之前政務(wù)釘釘?shù)那岸藞F隊做的 gdt-utils 來承載。
而可視化組件，則是由樂高 （ 阿里企業(yè)級可視化搭建平臺 ） 團隊提供的 vdev 工具鏈，而當(dāng)時還有一個問題是，由于 PC 端基于 React 框架，而小程序/移動端則基于 Rax 框架，導(dǎo)致可視化開發(fā)時也無法通過初始化一個包來完成 PC 和小程序端的開發(fā)。
總結(jié)起來，開發(fā)一個涵蓋三種模式的業(yè)務(wù)組件，需要適應(yīng)和學(xué)習(xí)三種工具鏈，初始化四個包，發(fā)布四個 npm package，而后續(xù)使用中，使用者需要記住四個包名以及他們對應(yīng)的使用場景，和在至少兩個地方看他們的使用方法。同時在維護的階段，PC 和 移動端相似的模型、請求、數(shù)據(jù)處理邏輯也無法得到復(fù)用，如果想要復(fù)用怎么辦？不好意思，那就需要再發(fā)一個工具包在幾個包之間做流轉(zhuǎn)。這些都在無形中增加了開發(fā)一個業(yè)務(wù)組件的成本，同學(xué)們的精力就在這些框架、包和聯(lián)調(diào)的過程中消耗掉了。
2. 融合開發(fā)
雖然從結(jié)果來看，這樣子可以完成開發(fā)，但從上手門檻和開發(fā)效率上來說確實不如人意，一是需要寫大量的文檔來把這件事情說清楚，二是僅僅為了開發(fā)一個業(yè)務(wù)組件，需要這么大的成本真的是一個好的方案嗎？那可不可以不要那么多東西，就一個工具鏈，一個包解決所有問題，這樣不好嗎？好是好，但真要這么做之前，有很多問題需要解決。
最大的問題在于，如何將 Rax 和 React 兩種框架有機結(jié)合在一個工具鏈中。這看似是一個不怎么困難的問題，貌似是只要把以前的 React 和 Rax 的 webpack 配置拿過來各跑各的就行了，但融合之后有些東西是合成一份的，比如 demo 文件，對于一個希望融合開發(fā)的同學(xué)來說，自然是不希望，寫幾份幾乎相同的 demo，僅僅是因為不同的運行框架帶來的引用不同。相似的還有可視化組件當(dāng)中的 prototypeView 文件，這個文件用于在樂高設(shè)計器中渲染組件，這里需要一點樂高組件開發(fā)的知識，prototypeView 文件的大致代碼組成是這樣的：
這樣的設(shè)計是在可視化組件都是 React 框架的前提下設(shè)計出來的，在以往的實踐中是沒有問題的。
但融合開發(fā)后，就像上面代碼中的注釋一樣，如何驅(qū)動一個 React 組件和一個 Rax 組件混合打包，并且可以正常渲染，需要有解決的辦法。 其次，從工程的角度，選取哪個工具鏈來實現(xiàn)這個融合開發(fā)的能力？ 顯然目前的每條工具鏈都不具備直接實現(xiàn)的能力，那是選取其中某一個進行增強，還是另起爐灶結(jié)合三者的能力？ 各有利弊，需要權(quán)衡。 還有一個必須考慮的點，就是如何盡量減少對開發(fā)者原有心智的改變，以及盡量保持對 Fusion 物料能力的匹配（如同步到 Fusion 站點），這樣才可以讓開發(fā)者以盡量少的代價遷移到新的開發(fā)模式上來。 確認了這些問題之后，我們開始著手通過 融合 開發(fā)來解決這個開發(fā)困境。
3. 著手解決
確定目錄架構(gòu)
首先我們需要確定融合開發(fā)包（后簡稱“融合包”）的目錄結(jié)構(gòu)：
從源碼結(jié)構(gòu)上，我們基本沿用了可視化組件的文件結(jié)構(gòu)，這樣一方面滿足了可視化組件特殊的要求（如設(shè)置器的配置，設(shè)計態(tài)的渲染等），另一方面通過制定 package.json 的 main 字段，也可以實現(xiàn)直接引用包名調(diào)用組件的需求。
而技術(shù)棧上則全面使用 ts 和 scss，和 Fusion 組件對齊，同時方便使用 scss 變量和 css 變量。
在構(gòu)建產(chǎn)物上，我們則結(jié)合了幾個工具鏈產(chǎn)物的特點，首先構(gòu)建 babel 轉(zhuǎn)譯過的 es5 文件和對應(yīng)的聲明文件，用于一般項目中。其次構(gòu)建保留的 import/export 的 esmodule，用于對包體積有要求的項目做 treeShaking。而后，將對應(yīng)的 md 構(gòu)建成可直接瀏覽器預(yù)覽的 demo 放在 build 文件夾中與 Fusion 組件對齊，再將 lib 文件夾下的文件復(fù)制到 build 目錄中，方便樂高構(gòu)建和識別（樂高構(gòu)建的時候會直接去找 build 目錄下的 view.js 和 view.mobile.js 等文件）。
工具鏈的選擇
在工具鏈的選擇上，我們最終選擇了樂高的開發(fā)套件 vdev 作為底座進行擴展，這樣做的考慮是可視化組件的整套開發(fā)體系較重，且未插件化，抽取遷移的成本較高。其次，相比其他兩套工具鏈，vdev 在大團隊的基礎(chǔ)架構(gòu)部門維護，溝通協(xié)作相對簡單。剩余的部分我們并沒有完全重造，而是盡可能地復(fù)用起現(xiàn)有的 build-scripts 體系下的插件。我們首先對 vdev 進行了改造，支持了 build-scripts 相關(guān)體系的調(diào)用，剩余的開發(fā)則基于 build-scripts 下的 plugin 開始開發(fā)，最終的大致鏈路如下：
pc.json 大致如下：
在開發(fā)的時候我們定下了一個原則，基于通用規(guī)則下的 PC、Mobile 和小程序預(yù)覽，我們盡量通過官方的 build-plugin-component 來實現(xiàn)，不支持的功能或 bug 通過共建補齊或修復(fù)，而針對融合包的特殊規(guī)則，如融合需要的特殊配置處理，構(gòu)建后的文件轉(zhuǎn)移等邏輯，通過 build-scripts 體系下后序插件（我們這里命名為 build-plugin-vdev-component）可以對前序插件定義的配置做進一步處理的特性來增加。這樣既減小了后續(xù)的維護成本，又可以通過 build-plugin-component 幫助到更多的業(yè)務(wù)。
確定好基礎(chǔ)的架構(gòu)之后，我進一步定義了融合包相關(guān)的 npm scripts：
start：用于啟動可視化部分的調(diào)試，包含設(shè)計器和預(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），剩下的主要是補全 build-plugin-component 中缺失的功能，比如 Rax 部分里對 scss 的支持，inlineStyle 配置的支持。有個值得稍微提一下的點是關(guān)于對 demo 文件中 jsx 的處理。我們都知道 jsx 是 React 提出的 js 的加強型語法，用于將模板可以完全使用 js 語法來描述，實際在瀏覽器是不能直接識別的，一般的處理方式是通過 babel 轉(zhuǎn)換成對應(yīng)的轉(zhuǎn)換語法，如把
轉(zhuǎn)換成：
對于的 jsx 標(biāo)簽如
demo 文件的寫法上是基于 PC 的視角的，引用的依賴是 react 的 Component 和 createElement，以及基礎(chǔ)組件庫 @ali/deep。在啟動小程序調(diào)試時，react alias 到 rax ，@ali/deep alias 到 @ali/deep-mobile。而 jsx 相關(guān)的，如
構(gòu)建主要解決的問題
在 build 的過程中，由于要同時構(gòu)建出 PC 和 Mobile 的 demo，而 build-plugin-component 只能啟動 Rax 或者 React 其中一邊的構(gòu)建，顯然這無法滿足我們的需求，如果調(diào)用兩次腳本，中間又存在著大量的重復(fù)操作，如文件夾的新增和刪除等等。 我們選擇的是使用 build-plugin-component 的 rax 部分，并在后序插件 build-plugin-vdev-component 里另起一個 React 的 webpa ck task，同時完成 PC 和 Mobile 的 demo 構(gòu)建。
在構(gòu)建 es5 的文件時，也遇到了 jsx 的編譯問題，由于源碼中包含了一部分 react 文件也包含了一部分 rax 文件，在 start 時還可以按照 entry 的依賴鏈來設(shè)置 babel 配置，但是 build 時對源文件只過 babel 沒有 webpack，所以要使用其他的辦法來處理。 我們采取的方式 是先分析每 個文件的 AST，從文件的包引用上分析出該文件是一個 React 還是 Rax 組件，然后采用不同的 babel 配置來進行編譯。 這里為什么沒有采用和上文提到的 demo 里的同樣的方式進行處理呢？ 原因是 demo 的方式對 createElement 的引入是強依賴，寫法上比較受限，在源碼部分我們希望能夠讓用戶擁有更靈活的使用方式。
這樣基本上在 ProCode 下的場景都可以正常使用了，但樂高環(huán)境下還不行，主要還是處在 prototypeView.tsx 這個文件的處理上，上面我們提到過，這個文件會同時引入 React 和 Rax 組件，雖然在設(shè)計態(tài)，只會有其中一個組件被真正渲染出來，但有些 API 是在組件類的聲明時就會用到，例如 Rax.forwardRef。這就導(dǎo)致不做任何處理的情況下，在設(shè)計態(tài)會因為缺少 API 而報錯無法使用。而樂高的組件保存構(gòu)建，和一般的 Procode 項目，是每個組件單獨構(gòu)建的，而組件在構(gòu)建時并不知道自己是要在樂高 PC（React 環(huán)境）還是樂高小程序（Rax 環(huán)境）里使用。所以我們在組件本地構(gòu)建時會額外生成一個 prototypeView.rax.js，這個文件在內(nèi)容和構(gòu)建后的 prototypeView.js 并沒有本質(zhì)區(qū)別，但是提供給樂高打包構(gòu)建一個額外的入口，樂高構(gòu)建時探測到是一個融合包時對這兩個文件入口配置不同的 webpack alias，在 prototypeView.js 里會將 rax 相關(guān)的 api alias 到 remaxjs 社區(qū)的 rax-compact 包上，用于樂高 PC 版設(shè)計態(tài)的展示（React 環(huán)境）。在 prototypeView.rax.js 中將 react 相關(guān)的 api alias 到 rax/lib/compact 上，用于樂高小程序設(shè)計態(tài)的展示（Rax 環(huán)境）。
4. 最終效果
最終我們將業(yè)務(wù)組件的開發(fā)和使用過程，統(tǒng)一到了一個包（融合 vc 包），一個工具鏈（vdev：初始化、調(diào)試、發(fā)布），對 @ali/deep 和 @ali/deep-mobile 這兩個基礎(chǔ)組件包實現(xiàn)按需加載編譯（也支持 Fusion/Antd）。使用的時候，無論 PC 端、小程序還是可視化的部分，都可以引用同一個包，沒必要去記住不同的包名和他們對應(yīng)的平臺。正常情況下，我們可以通過直接引用包名來引入 PC 部分，通過 es/view.mobile（或者 lib/view.mobile） 引入移動端/小程序部分。另外，這里我們在 package.json 里將對應(yīng)的入口也做了注冊，這樣可以通過 webpack resolve 配置也可以實現(xiàn)通過包名就直接引用移動端部分的效果。
1 困境
融合開發(fā)的第一個版本，解決了開發(fā)者在項目工程維護、發(fā)布和使用者使用包時的耗費心智的問題，同時對于在 PC 和 Mobile 復(fù)用邏輯上有較大幫助。但開發(fā)者在開發(fā)過程中仍有很多重復(fù)勞動的過程。比如雖然已經(jīng)有了完整的 ts 支持和接口聲明，但是用戶還是需要自己配置組件的 setter，配置 setter 組件的過程主要是指定 setter 對應(yīng)的屬性，默認值和類型。比如組件發(fā)布之后，還需要通過一套入駐機制，才能在物料中心給自己和他人查看 Demo。比如小程序調(diào)試，每次本地啟動構(gòu)建后，還要打開小程序的 IDE。這些都是每個業(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 中要求一個文件中只有一個 Class 聲明，再加上 Component 的 ts 泛型，這些前提條件讓我們可以定位到 props 的接口，從而得到每個 prop 的 name 和類型。考慮到業(yè)務(wù)組件的最重要目的是能夠快速在樂高里使用起來，所以我們沒有必要對每種類型和默認值做特別精細化的映射，我們可以為基礎(chǔ)類型找到對應(yīng)的 setter，對一些復(fù)雜的類型指定為一個 JSONSetter，對渲染函數(shù)鉤子指定為 ActionSetter，對回調(diào)事件指定為 events。prototype.tsx 的模板文件也是一個比較標(biāo)準(zhǔn)的寫法，因此我們可以比較方便地通過 AST 分析出已經(jīng)定義過的屬性，這些屬性不需要再增加一遍，以及插入新屬性代碼的位置，通過直接生成這部分設(shè)置器代碼，我們的組件基本上可以在不需要修改的情況下在設(shè)計器里正常使用起來（指可以配置各個屬性，流暢地使用組件的各個功能，而非僅是展示）。
3 發(fā)布自動同步物料中心
組件發(fā)布只是第一步，一個業(yè)務(wù)組件只有能夠被發(fā)現(xiàn)，文檔可以被閱讀，才是組件服務(wù)的開始。在企業(yè)智能，我們目前統(tǒng)一使用物料中心進行組件的展示。過去的業(yè)務(wù)組件只能通過物料中心后臺配置的方式才能上架到物料中心，這個過程需要大量的手動填寫的東西，耗時耗力。這部分我們也做了優(yōu)化，在組件發(fā)布到 tnpm 后，vdev 來收集上架必要的信息，如組件 owner，組件分屬業(yè)務(wù)領(lǐng)域，組件適配的端等等，物料中心提供 API 調(diào)用，直接將這些信息同步至物料中心，實現(xiàn)一鍵發(fā)布+上架物料中心的效果。當(dāng)然，這個同步并非強制，對于一些測試版，可以選擇不進行同步。
4 小程序 WebIDE 調(diào)試
原有小程序調(diào)試必須要在本地構(gòu)建出一個符合小程序結(jié)構(gòu)的項目目錄，然后再使用小程序 IDE 打開對應(yīng)目錄才能開始調(diào)試，這個過程跨越多個工具鏈，學(xué)習(xí)成本和操作成本都比較高。恰好支付寶小程序團隊推出了 @ali/mini 工具鏈，可以基于項目目錄下一鍵啟動 Lyra 瀏覽器模擬器進行調(diào)試。我們?nèi)诤祥_發(fā)包也對 @ali/mini 做了集成，@ali/mini 需要的配置文件自動幫助組件開發(fā)者生成，通過一個命令就可以直接啟動 WebIDE 進行調(diào)試了。
1 困境
上面兩部分，我們主要圍繞的是一個純 UI 的業(yè)務(wù)組件開發(fā)，但我們也知道很多業(yè)務(wù)模塊都是需要配合后端服務(wù)一起使用才能完整表達一個場景，最簡單的例子就是一個搜人組件，不搭配服務(wù)就是一個列表樣式有點特殊的選擇組件。
對于這類組件，以前有兩種策略，一是搭配一個跨域的 jsonp 接口，但隨著目前安全越來越收緊的情況下，這類接口越來越少了。另一個就是搭配一個業(yè)務(wù)上的接口，但這類接口和組件聯(lián)調(diào)非常麻煩，因為接口只有在對于的業(yè)務(wù)域名下才能使用，因為這個限制條件，就分出了兩種不同的思路，一個是要在業(yè)務(wù)域上做個頁面出來或者干脆直接在業(yè)務(wù)項目里去調(diào)，更有甚者，前端直接把后端服務(wù)起起來本地調(diào)，想想都感覺很麻煩，新接手的同學(xué)估計光搭個環(huán)境就要花很長的時間。
另一個策略就是前端使用 mock 的接口或者數(shù)據(jù)進行調(diào)試，這類環(huán)境上相對簡單一點，但帶來很大的聯(lián)調(diào)成本，首先 mock 接口有時很難模擬線上真實數(shù)據(jù)，其次誰去一直維護這個接口一直和線上保持一致，帶來了額外的工作量。開發(fā)不方便，使用也不方便，由于接口是業(yè)務(wù)自己的，導(dǎo)致本地或者樂高里啟動調(diào)試的時候，接口無法調(diào)通，只能花力氣部署到業(yè)務(wù)頁面上才能使用起來看效果?；蛘呤沁x擇組件里不默認攜帶服務(wù)，真正使用的時候再去配對應(yīng)的接口，就出現(xiàn)了拿著組件去找接口的情況，接口本身有很多種形式，能 run 起來的方式也不一樣，能真正用起來看效果，也要花一段時間。
2 服務(wù)調(diào)用
上面的分析中可以看出，這類組件的主要難點在于服務(wù)的調(diào)用上，在沒有跨域請求接口的情況下，本地開發(fā)舉步維艱。所以核心問題在于提供一類服務(wù)，可以方便地在本地或者樂高環(huán)境調(diào)用，同時不用擔(dān)心安全問題（數(shù)據(jù)泄露和服務(wù)提供方壓力等），這就需要一個 API 網(wǎng)關(guān)來，這個網(wǎng)關(guān)可以解決服務(wù)調(diào)用的鑒權(quán)，以及對服務(wù)提供方進行保護。有了網(wǎng)關(guān)的情況下，下一步要解決的本地和樂高如何調(diào)用的問題，樂高調(diào)用相對來說比較簡單，樂高本身是有后端服務(wù)的，只需要提供一個過程，在用戶接入某個組件和服務(wù)的時候，到網(wǎng)關(guān)去自動申請日常服務(wù)的調(diào)用，由于日常服務(wù)大多已做了數(shù)據(jù)脫敏，且與真實數(shù)據(jù)隔離不能直接用于生產(chǎn)，所以日常服務(wù)的訂閱申請和審批都是相對比較簡單的，這個過程可以在開通組件的背后直接完成。本地調(diào)用則相對會比較麻煩，一般本地調(diào)試都是 node 起一個本地 server（如 webpack dev server 等），背后很難直接完成接口的調(diào)用。這里有兩種解決思路，一個是服務(wù)端提供一個日常的跨域調(diào)用的轉(zhuǎn)發(fā)接口，用于轉(zhuǎn)發(fā)網(wǎng)關(guān)服務(wù)，如 /api/gateway?id=epaas.api.key，另一個則是服務(wù)端提供一個模板頁面，前端 server 提供 js 和 css，并注入到對應(yīng)的頁面中，這樣直接請求對應(yīng)的接口即可。
3 實踐
在 EI 的實踐中，恰好有這樣一個業(yè)務(wù)網(wǎng)關(guān) ePaaS 來承載網(wǎng)關(guān)的職責(zé)，在樂高的使用側(cè)，我們設(shè)計了一個業(yè)務(wù)能力模塊來做對應(yīng)的組件和服務(wù)開通，ePaaS 是通過應(yīng)用間的服務(wù)訂閱來實現(xiàn)跨業(yè)務(wù)調(diào)用的，所以我們在開通業(yè)務(wù)能力前會先讓用戶填寫自己的 ePaaS，其實樂高預(yù)覽時這些是不需要的，讓用戶填寫是為了幫助用戶一鍵完成自己 ePaaS 這些接口的訂閱，而不需要用戶再自己去 ePaaS 上一個個手動訂閱了。
ePaaS 的功能介
當(dāng)然 ePaaS 網(wǎng)關(guān)不是最終唯一的選擇，我們也在積極拓展其他網(wǎng)關(guān)的接入。
構(gòu)建效率提效：上面做的事情只是做到能，但還遠稱不上好，尤其是經(jīng)常啟動的調(diào)試命令，還有巨大的優(yōu)化空間，每個人每次節(jié)省 10s，加起來也是好多時間。
深入業(yè)務(wù)：目前在企業(yè)智能的一些業(yè)務(wù)域下已經(jīng)鋪開，但還沒有完全覆蓋，這套東西是從業(yè)務(wù)里來的，所以也應(yīng)該回到業(yè)務(wù)里去，業(yè)務(wù)的邊界場景會帶領(lǐng)我們逐漸進入深水區(qū)。
業(yè)務(wù)能力：能力是個比較虛的詞，在我這里的理解，他是一個以一個業(yè)務(wù)功能為核心的，不定數(shù)量個服務(wù)和UI（頁面、區(qū)塊、組件）的集合，帶服務(wù)的業(yè)務(wù)組件是我們在這個領(lǐng)域的第一步探索，接下來我們會把他繼續(xù)做深入，包括業(yè)務(wù)能力的樂高入駐，業(yè)務(wù)能力的本地生產(chǎn)等等。
LowCode：目前樂高已經(jīng)具備了低代碼拖拽生成業(yè)務(wù)組件的能力，但只能在低代碼可視化的設(shè)計器里使用，而理想狀態(tài)下應(yīng)該是可以在各種狀態(tài)下流通，但是否是業(yè)務(wù)上的痛點，這個還在收集中。
模型驅(qū)動？：這個點打了一個問號，是因為目前還只是一個想法的階段。目前頁面在企業(yè)智能已經(jīng)實現(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ì)量的實用文章！
重慶分公司
重慶分公司
