登上 Github 趨勢榜，iMove 原理技術(shù)大揭秘!
我認(rèn)為前端開發(fā)中問題很多，尤其是以下3點(diǎn)。
-
UI老變，導(dǎo)致開發(fā)必須跟緊
-
邏輯挑戰(zhàn)，開發(fā)也必須改代碼，很多后端處理邏輯都在里面
-
組合接口，這是歷史原因，主要是和后端配合導(dǎo)致的。其實(shí)沒有Node BFF層，都由組件來做，會(huì)問題非常多。
最近我們的開源項(xiàng)目 iMove 一天就漲了 280+ star，一舉登上了 github 趨勢榜第 1 名，取得的成績還是不錯(cuò)的，說明這個(gè)項(xiàng)目定位準(zhǔn)確，確確實(shí)實(shí)解決了開發(fā)者問題。
今天，就通過本篇文章和大家介紹一下 iMove 開源項(xiàng)目，內(nèi)容包含iMove功能和實(shí)現(xiàn)原理、獨(dú)創(chuàng)的在線代碼運(yùn)行能力，以及如何自動(dòng)解析節(jié)點(diǎn)的npm包依賴，還是有非常多亮點(diǎn)和創(chuàng)新的。
關(guān)于 iMove
簡單講，其實(shí)我們理想的前端可以做以下4點(diǎn)。
-
邏輯可組裝：其實(shí)是接口和UI在最小粒度上的復(fù)用。
-
流程可視化：這些可復(fù)用的最小單元，可以通過流程來進(jìn)行編排，繼而達(dá)到讓運(yùn)營簡化的目的。
-
運(yùn)營配置收斂：這是因?yàn)槎嗵紫到y(tǒng)導(dǎo)致運(yùn)營成本很高導(dǎo)致的，統(tǒng)一放到一起最好。
-
玩法能力沉淀：促使產(chǎn)品將玩法進(jìn)行沉淀，變成可復(fù)用的能力。
對開發(fā)者而言，iMove恰好是可以完成這些目標(biāo)的理想工具。動(dòng)動(dòng)鼠標(biāo)，寫一下節(jié)點(diǎn)函數(shù)，代碼導(dǎo)出，放到具體工程里就可以直接使用，是不是很方便？
那么，什么是 iMove?
-
它是個(gè)工具，無侵入性。
-
雙擊編寫函數(shù)，編排后的流程可以導(dǎo)出可執(zhí)行代碼，便于在具體項(xiàng)目里做集成。
-
測試方便，右鍵直接執(zhí)行，此處有創(chuàng)新。
-
讓開發(fā)像運(yùn)營配置一樣完成功能開發(fā)，做到復(fù)用和Lowcode。
舉個(gè)栗子
上面這些介紹，也許看著沒什么體感，不容易理解，讓我們一起來看個(gè)例子~
假如有天你接到了一個(gè) 詳情頁購買按鈕 的需求：
-
獲取詳情頁的商品信息
-
商品信息包含以下
-
-
當(dāng)前用戶是否已經(jīng)領(lǐng)券
-
商品領(lǐng)券是需要關(guān)注店鋪還是加入會(huì)員
-
-
根據(jù)返回的商品信息，購買按鈕有以下幾種形態(tài)
-
-
如果已經(jīng)領(lǐng)券，按鈕展示 "已領(lǐng)券 + 購買"
-
如果沒有領(lǐng)券
-
-
-
-
如果領(lǐng)券需要關(guān)注店鋪，按鈕展示 "關(guān)注店鋪領(lǐng)券 + 購買"
-
如果領(lǐng)券需要加入會(huì)員，按鈕展示 "加入會(huì)員領(lǐng)券 + 購買"
-
-
-
-
異常情況時(shí)，展示兜底樣式
-
-
注意：如果用戶未登錄，喚起登錄頁
我們可以將以上這段復(fù)雜的業(yè)務(wù)邏輯轉(zhuǎn)化成如下這段示意偽代碼：
- // 檢查登錄
- const checkLogin = () => {
- return requestData('/is/login').then((res) => {
- const {isLogin} = res || {};
- return isLogin;
- }).catch(err => {
- return false;
- });
- };
- // 獲取詳情頁數(shù)據(jù)
- const fetchDetailData = () => {
- return requestData('/get/detail/data').then((res) => {
- const {
- hasApplied,
- needFollowShop,
- needAddVip,
- } = res;
- if(hasApplied) {
- setStatus('hasApplied');
- } else {
- if(needFollowShop) {
- setStatus('needFollowShop');
- } else if(needAddVip) {
- setStatus('needAddVip');
- } else {
- setStatus('exception');
- }
- }
- }).catch(err => {
- setStatus('exception');
- });
- };
- checkLogin().then(isLogin => {
- if(isLogin) {
- return fetchDetailData();
- } else {
- goLogin();
- }
- });
誠如上述例子所示，雖然業(yè)務(wù)復(fù)雜度并不是非常高，但其背后的溝通和理解成本其實(shí)并不低，想必大家在各自業(yè)務(wù)中遇到的實(shí)際場景比這復(fù)雜棘手得多。然而，業(yè)務(wù)邏輯的復(fù)雜度決定了代碼的復(fù)雜度，越復(fù)雜的代碼越難維護(hù)，假如某天你接手了一個(gè)邏輯很復(fù)雜的他人項(xiàng)目，這其中的維護(hù)成本是非常高的。不過這也正是 iMove 所解決的問題之一，面對上述同樣的業(yè)務(wù)需求，我們來看看使用 iMove 是如何開發(fā)的。
如上所示，原本晦澀難懂的代碼邏輯通過 iMove 以流程圖的形式表達(dá)了出來，現(xiàn)在產(chǎn)品的業(yè)務(wù)邏輯一目了然。除此之外， iMove 中的每個(gè)節(jié)點(diǎn)都是支持編寫代碼的，而流程圖的走向又決定了圖中節(jié)點(diǎn)的執(zhí)行順序，可以說 "流程可視化即天然的代碼注釋" 。
因此，就從 "易讀性" 和 "可維護(hù)性" 上來看： iMove 流程可視化的形式 > 產(chǎn)品經(jīng)理的 PRD 文字描述形式 > 程序代碼形式。
應(yīng)用場景
前端React組件一般在ComponentDidMount里發(fā)起請求，根據(jù)請求成功的數(shù)據(jù)完成渲染或其他業(yè)務(wù)邏輯，這種是完全無UI的Ajax請求處理。除了組件聲明周期，就只有各種交互事件里，這里面一般是UI和Ajax混用的場景。
-
前端流程，比如點(diǎn)擊事件，組件生命周期回調(diào)等。
-
后端流程，比如Node.js或Serverless領(lǐng)域。
-
前端+后端，比如前端點(diǎn)擊事件，Ajax請求和后端API。
優(yōu)勢
上文提到的內(nèi)容只是 iMove 的冰山一角，我們一起來看下 iMove 都有哪些優(yōu)勢：
1）邏輯可復(fù)用
面對頻繁迭代的日常業(yè)務(wù)需求，我們一定會(huì)遇到許多相似、重復(fù)的開發(fā)工作。體現(xiàn)在代碼中它可以是一段通用的 utils 工具方法，也可以是一段通用的業(yè)務(wù)邏輯代碼（比如分享），但究其本質(zhì)它們就是一個(gè) 代碼片段 。為了提高代碼的復(fù)用，我們往往會(huì)將其封裝成一些通用的類或函數(shù)，然后在各個(gè)項(xiàng)目中拷貝粘貼（做得好一點(diǎn)可以將其封裝成 npm 包，但修改發(fā)布的流程又會(huì)稍顯繁瑣）。
而在 iMove 中，每個(gè)可復(fù)用的代碼片段都可以被封裝成流程圖中的節(jié)點(diǎn)。當(dāng)想在不同項(xiàng)目中復(fù)用邏輯的時(shí)候，直接引入對應(yīng)的節(jié)點(diǎn)/子流程即可，每個(gè)節(jié)點(diǎn)還支持參數(shù)配置，進(jìn)一步提升了節(jié)點(diǎn)的復(fù)用性，使用體驗(yàn)可以說是非常簡單了。
再往后設(shè)想一步，假如 iMove 已經(jīng)在某個(gè)業(yè)務(wù)場景中沉淀了一定量的業(yè)務(wù)節(jié)點(diǎn)，當(dāng)下次再遇到相似的業(yè)務(wù)需求時(shí)，邏輯部分是否可以直接復(fù)用現(xiàn)成的節(jié)點(diǎn)拼裝而成。這可是大大提升了研發(fā)效率，縮短了項(xiàng)目的研發(fā)周期。
2）面向函數(shù)
在節(jié)點(diǎn)的設(shè)計(jì)方面， iMove 做得比較克制，每個(gè)節(jié)點(diǎn)其實(shí)就是導(dǎo)出一個(gè)函數(shù)，因此編碼體驗(yàn)上幾乎沒有什么上手成本，只要你有JavaScript基礎(chǔ)就能使用。你可以照常 import 其他 npm 包，也不用考慮節(jié)點(diǎn)之間的全局變量命名污染等問題，將它當(dāng)做一個(gè)普通的 js 文件即可。
3）流程可視化
我們將流程可視化的這種開發(fā)方式稱之為 "邏輯編排" ，它的好處（邏輯表達(dá)更為直觀，易于理解）前文已經(jīng)介紹過，這里就不再重復(fù)贅述。
4）邏輯/UI 解耦
我們在日常業(yè)務(wù)開發(fā)中經(jīng)常會(huì)遇到： UI 樣式經(jīng)常變化，而業(yè)務(wù)邏輯較為穩(wěn)定，甚至還會(huì)有 ABTest 需求查看改版效果 。
然而許多開發(fā)者在組件開發(fā)之初并不會(huì)設(shè)想到將來會(huì)有這一步，因此一個(gè)業(yè)務(wù)組件往往會(huì)將 "業(yè)務(wù)邏輯" 和 "UI樣式" 耦合在一起。而到了改版的時(shí)候才會(huì)發(fā)現(xiàn)要想抽離和復(fù)用業(yè)務(wù)邏輯并不容易，維護(hù)成本也大大增加。
不過當(dāng)你使用 iMove 開發(fā)之后就會(huì)發(fā)現(xiàn)：組件代碼自然而然就拆成了 "業(yè)務(wù)邏輯" + "UI樣式"。而且，不同版本的 UI 可以維護(hù)多套，但業(yè)務(wù)邏輯部分只要交給 iMove 維護(hù)一套即可。這樣的開發(fā)方式不僅可以最大程度地復(fù)用業(yè)務(wù)邏輯代碼，而且還提高了項(xiàng)目的可維護(hù)性。
5）更簡單的代碼測試
為了提升 iMove 的使用體驗(yàn)，我們實(shí)現(xiàn)了 "瀏覽器端在線運(yùn)行節(jié)點(diǎn)代碼" 的功能。這意味著當(dāng)完成一個(gè)節(jié)點(diǎn)的函數(shù)功能時(shí)，你隨時(shí)可以在瀏覽器端 mock 各種輸入來測試該節(jié)點(diǎn)的運(yùn)行結(jié)果是否符合你的預(yù)期。
也就是說，在無須引入測試框架、脫離上下文環(huán)境的前提下，你就可以單獨(dú)對某一個(gè)節(jié)點(diǎn)的函數(shù)進(jìn)行測試，這大大降低了代碼測試的成本和門檻。與此同時(shí)，你還可以順手將每次的測試輸入/輸出作為測試用例進(jìn)行保存，漸而形成一份完備的測試用例，這不但可以保障該節(jié)點(diǎn)的代碼質(zhì)量，還可以更放心得被引用在其他項(xiàng)目當(dāng)中。
6）無語言/場景限制
雖然 iMove 本身是一個(gè) JavaScript 工具庫，但在我們的設(shè)計(jì)中 iMove 并沒有對使用語言和場景加以限制。也就是說，你不僅可以用 iMove 編排前端項(xiàng)目中的 js 代碼，同樣也可以用 iMove 編排后端項(xiàng)目中的 java 代碼，甚至其他場景的其他語言。而這一切，其實(shí)最終只取決于 iMove 將流程圖編譯出碼成什么語言而已。
iMove 原理
在對 iMove 的項(xiàng)目背景有了一定了解后，本文接下來將帶大家一起揭開它背后的技術(shù)原理~
如何搭建可繪制的流程圖應(yīng)用？
拋開 iMove 偏開發(fā)的功能不說，大家完全可以把它當(dāng)做一個(gè)流程圖的繪制工具來使用（畫完之后還可以導(dǎo)出圖片保存到本地~）。那么 iMove 又是如何繪制流程圖的呢？想必大家一定對此比較好奇，這里必須得給螞蟻團(tuán)隊(duì)做的 X6 引擎點(diǎn)個(gè)贊 :+1: ，真的很好用~
X6 本身并不和 React 或 Vue 捆綁，因此你可以在任何框架內(nèi)配合 X6 一起使用。除此之外，它提供了一系列開箱即用的交互組件和簡單易用的節(jié)點(diǎn)定制能力，只需簡單調(diào)用一些 API 就能快速實(shí)現(xiàn)相應(yīng)的功能。
點(diǎn)擊i
后續(xù)我們會(huì)專門出一篇文章介紹 iMove 如何使用 X6 快速搭建一個(gè)可繪制的流程圖應(yīng)用。
imove的核心就是基于x6協(xié)議實(shí)現(xiàn)的。
-
有節(jié)點(diǎn)：利用x6的可視化界面，便于復(fù)用和編排。
-
有指向邊：即流程可視化，簡單直觀，邊上還可以帶參數(shù)。
-
有function和schema2form，支持函數(shù)定義，這是面向開發(fā)者的。支持form，讓每個(gè)函數(shù)都可以配置入?yún)ⅲ@部分是基于阿里開源的form-render實(shí)現(xiàn)的。
整個(gè)項(xiàng)目難度不大，基于x6和form-render進(jìn)一步整合，將寫法規(guī)范化，將編排工具化，這樣克制的設(shè)計(jì)使得imove具備小而美的特點(diǎn)，便于開發(fā)使用。
如何將流程圖編譯成可運(yùn)行代碼？
相比于繪制流程圖， iMove 更吸引人的是它可以將流程圖編譯成業(yè)務(wù)項(xiàng)目中可實(shí)際運(yùn)行的代碼。
在線編譯 vs 本地編譯
首先， iMove 既支持瀏覽器端在線編譯提供 zip 包下載，也支持本地命令行 watch 實(shí)時(shí)編譯出碼。
1）在線編譯
為了降低 iMove 的上手成本，我們加入了瀏覽器端在線編譯出碼的功能，這樣開發(fā)者無須安裝工具就能直接下載編譯好的代碼。
具體該如何實(shí)現(xiàn)呢？經(jīng)過調(diào)研，我們發(fā)現(xiàn) jszip 是一個(gè)集讀/寫/改 zip 文件于一身的 JavaScript 庫，而且還支持瀏覽器端運(yùn)行。因此，我們完全可以按照出碼的文件目錄生成一個(gè) json 丟給 jszip 打包，最后再用 file-saver 提供下載即可。
- // key 是"文件/目錄名"，value 是對應(yīng)的"文件內(nèi)容"
- {
- "nodeFns": {
- "node1.js": "...",
- "node2.js": "...",
- "index.js": "..."
- },
- "context.js": "...",
- "dsl.json": "...",
- "index.js": "...",
- "logic.js": "..."
- }
2）本地編譯
在線編譯的方式固然簡單，但在項(xiàng)目開發(fā)中會(huì)遇到一個(gè)問題： 每次修改代碼都需要重新下載 zip 包并解壓到指定目錄，尤其是調(diào)試時(shí)需要頻繁修改代碼會(huì)非常不便 。為了解決這個(gè)問題， iMove 提供了本地編譯的方式，通過 watch 流程圖的保存操作，實(shí)時(shí)地編譯出碼到業(yè)務(wù)項(xiàng)目中。
具體該如何實(shí)現(xiàn)呢？上述問題的關(guān)鍵在于： 本地如何監(jiān)聽瀏覽器端的流程圖保存操作 。但是反過來想，為什么不可以是 流程圖在保存時(shí)發(fā)送消息通知本地呢？ 這么一來，我們既可以使用 socket.io 等類庫在瀏覽器和本地之間建立 websocket 通信，也可以使用 koa / express 等類庫在本地啟動(dòng)一個(gè) http 服務(wù)器，只要在接收到流程圖保存信號時(shí)觸發(fā)編譯出碼即可。
iMove 代碼運(yùn)行基本原理
解決完 iMove 如何編譯代碼的問題，再來看看 iMove 編譯的代碼又是如何運(yùn)行的。
要想運(yùn)行代碼， iMove 需要解決兩個(gè)核心問題：
-
如何按流程圖的順序依次執(zhí)行節(jié)點(diǎn)
-
如何處理數(shù)據(jù)流（比如上一節(jié)點(diǎn)的返回值是下一節(jié)點(diǎn)的輸入）
RxJS 看起來是個(gè)不錯(cuò)的選擇，函數(shù)響應(yīng)式編程似乎天然解決上面的問題。但考慮到它的上手成本無疑會(huì)對 iMove 的使用者造成巨大的心智負(fù)擔(dān)，因此最終我們并沒有采用這套方案。
1）對于第一個(gè)順序執(zhí)行問題， iMove 采用了一種低成本的方式來解決：
-
首先，
X6支持導(dǎo)出流程圖的json數(shù)據(jù)，我們可以將其精簡處理后保存為一份DSL文件。 -
其次，根據(jù)這份
DSL文件，我們可以從中提取出每個(gè)節(jié)點(diǎn)的代碼部分成為單獨(dú)的文件，進(jìn)而構(gòu)成一個(gè) 節(jié)點(diǎn)函數(shù)集 。 -
最后，接下來只要按照 節(jié)點(diǎn)和邊的上下游關(guān)系 順序調(diào)用相應(yīng)的節(jié)點(diǎn)函數(shù)即可。
2）對于第二個(gè)數(shù)據(jù)流問題， iMove 考慮到實(shí)際應(yīng)用中節(jié)點(diǎn)對數(shù)據(jù)操作的各種場景，一共設(shè)計(jì)了四種數(shù)據(jù)讀寫方式:
-
config:只讀型，每個(gè)節(jié)點(diǎn)的投放配置，節(jié)點(diǎn)之間互不干擾。
-
payload: 只讀型，
logic.invoke觸發(fā)邏輯時(shí)，可以傳一個(gè)payload值，每個(gè)節(jié)點(diǎn)都能讀取該值。 -
pipe:只讀型，上一個(gè)節(jié)點(diǎn)的輸出是下一個(gè)節(jié)點(diǎn)的輸入。
-
context: 可讀寫，某一個(gè)邏輯流中的公有數(shù)據(jù)，如果祖先節(jié)點(diǎn)又通過
setContext設(shè)置數(shù)據(jù)，那么子孫節(jié)點(diǎn)可以跨節(jié)點(diǎn)通過getContext訪問到該數(shù)據(jù)
至此， iMove 解決了流程圖代碼運(yùn)行的問題。如果你有注意 iMove 編譯后的代碼，就能看到如下結(jié)構(gòu)：
理解Flow
Flow的基本概念很簡單，就是一個(gè)有向無環(huán)圖（DAG），數(shù)據(jù)在節(jié)點(diǎn)間流動(dòng)。
-
節(jié)點(diǎn) Node
-
-
節(jié)點(diǎn)是組成流的主要單元，負(fù)責(zé)對流入節(jié)點(diǎn)的數(shù)據(jù)進(jìn)行處理，并輸出到后續(xù)節(jié)點(diǎn)進(jìn)行進(jìn)一步的處理。
-
-
端口 Port
-
-
每個(gè)節(jié)點(diǎn)擁有輸入和輸出端口，輸入端口負(fù)責(zé)數(shù)據(jù)流入節(jié)點(diǎn)，輸出端口負(fù)責(zé)數(shù)據(jù)流出節(jié)點(diǎn)。每個(gè)節(jié)點(diǎn)都可能擁有一個(gè)或者多個(gè)輸入和輸出端口。
-
-
連接 Link
-
-
一個(gè)節(jié)點(diǎn)的輸出端口連接到另一個(gè)節(jié)點(diǎn)的輸入端口，節(jié)點(diǎn)處理好的數(shù)據(jù)通過連接流入其后的節(jié)點(diǎn)。
-
Flow的實(shí)現(xiàn)基本思路就是用一個(gè)函數(shù)function實(shí)現(xiàn)一個(gè)節(jié)點(diǎn)，輸入端口映射為函數(shù)的輸入?yún)?shù)。輸出端口映射為函數(shù)的返回值。
流中有一個(gè)節(jié)點(diǎn)被設(shè)置為終點(diǎn)節(jié)點(diǎn)（End Node），通過節(jié)點(diǎn)間的連接關(guān)系，以終點(diǎn)節(jié)點(diǎn)開始通過連接搜索所有的依賴關(guān)系（樹形查找），得到一個(gè)節(jié)點(diǎn)運(yùn)行的棧。例如上圖，我們就可以得到一個(gè) [node1，node2, node3] 這樣的棧。按順序出棧的方式執(zhí)行每一個(gè)節(jié)點(diǎn)的功能就可以運(yùn)行整個(gè)流。（注意，這是一個(gè)簡單版本的Flow的實(shí)現(xiàn)，仍然是一個(gè)批處理，不是streaming）
需要假定每一個(gè)節(jié)點(diǎn)的功能是無狀態(tài)的，這樣就可以利用輸入輸出端口對計(jì)算結(jié)果進(jìn)行緩存，但輸入值是已經(jīng)運(yùn)算過的值的時(shí)候，不需要運(yùn)算，直接返回已經(jīng)計(jì)算過的值。
以上是Flow-base programing（FBP）里的Flow概念。其實(shí)這和imove里的概念是一樣的。imove基于x6，x6解決了DAG實(shí)現(xiàn)和可視化問題，再結(jié)合節(jié)點(diǎn)擴(kuò)展函數(shù)寫法，繼而實(shí)現(xiàn)面向開發(fā)者的邏輯編排工具。殊途同歸，就是這么簡單。
如何在線運(yùn)行節(jié)點(diǎn)代碼？
iMove 有個(gè)比較 cool 的功能就是可以在瀏覽器端在線運(yùn)行節(jié)點(diǎn)函數(shù)代碼，實(shí)時(shí)看到運(yùn)行結(jié)果。這種 所見即所得 的開發(fā)體驗(yàn)對使用者來說還是很友好的，不但測試調(diào)試的成本大大降低，還能成為測試用例集進(jìn)一步保障節(jié)點(diǎn)質(zhì)量。
在 iMove 里編寫代碼，雙擊節(jié)點(diǎn)即可。
右鍵執(zhí)行代碼，即可完成對單個(gè)節(jié)點(diǎn)的測試。
打開運(yùn)行面板，填寫對應(yīng)參數(shù)，即可執(zhí)行具體代碼。
在線運(yùn)行 iMove 節(jié)點(diǎn)代碼需要解決以下一些問題：
-
瀏覽器端如何直接運(yùn)行節(jié)點(diǎn)中的
import/export等esm規(guī)范代碼 -
節(jié)點(diǎn)中
import進(jìn)來的npm包還有可能是cjs規(guī)范，瀏覽器又該如何運(yùn)行 -
同時(shí)選中多個(gè)節(jié)點(diǎn)時(shí)，又該如何運(yùn)行代碼
iMove 實(shí)現(xiàn)的背后原理主要還是借助 http-import ，后面我們會(huì)專門出一篇文章介紹它的實(shí)現(xiàn)原理，敬請期待~
如何自動(dòng)解析節(jié)點(diǎn)的 npm 包依賴？
由于每個(gè) iMove 的節(jié)點(diǎn)都支持 import 其他 npm 包，因此每個(gè)節(jié)點(diǎn)都有 npm 依賴。但是，如果這項(xiàng)工作讓開發(fā)者手動(dòng)填寫體驗(yàn)會(huì)非常差，因此我們做了自動(dòng)解析的功能。
原理其實(shí)比較簡單，了解 npm view 命令即可。就拿 npm view lodash.get 舉例來說，查看命令行輸出可以看到:
- $ npm view lodash.get
- lodash.get@4.4.2 | MIT | deps: none | versions: 13
- The lodash method `_.get` exported as a module.
- https://lodash.com/
- dist
- .tarball: https://r.cnpmjs.org/lodash.get/download/lodash.get-4.4.2.tgz
- .shasum: 2d177f652fa31e939b4438d5341499dfa3825e99
- maintainers:
- - phated <blaine.bublitz@gmail.com>
- dist-tags:
- latest: 4.4.2
- published over a year ago by jdalton <john.david.dalton@gmail.com>
如上所述，該命令成功獲取到 lodash.get 這個(gè)包的最新版本。當(dāng)然， npm view 命令不適合在瀏覽器端執(zhí)行，但究其本質(zhì)都會(huì)走網(wǎng)絡(luò)請求查詢。我們再用 npm view lodash.get --verbose 就能看到執(zhí)行過程中其實(shí)發(fā)起了請求: https://r.cnpmjs.org/lodash.get 。
接下來就很簡單了，只要根據(jù) import 語法規(guī)則用正則匹配出節(jié)點(diǎn)代碼中的依賴，再調(diào)用上面的 api 就可以自動(dòng)解析出該節(jié)點(diǎn)的包依賴了。
總結(jié)
在UI側(cè)有imgcook這樣的設(shè)計(jì)稿轉(zhuǎn)代碼的工具，應(yīng)對變化是足夠的。但在邏輯領(lǐng)域，真正能解決問題的又面向開發(fā)者的少之又少，imove算這個(gè)方向的一個(gè)探索。相信通過上面的講解，大家都能夠感受到它的魅力。
imove的口號是 Move your mouse, generate code from flow chart ，即動(dòng)動(dòng)鼠標(biāo)，寫一下節(jié)點(diǎn)函數(shù)，代碼導(dǎo)出，放到具體工程里就可以直接使用。像運(yùn)營配置一樣開發(fā)，這已經(jīng)不是愿望，而是已經(jīng)實(shí)現(xiàn)了的。
