模組是 Korat 給出的答案。用一個應用同時服務餐廳、酒店、診所和零售店,麻煩在於:誠實的版本是四個共用登入的應用,不誠實的版本是一個設定介面大到每家店看到的大多是與自己無關的東西的應用。Korat 走第三條路:業務型別選中模組,模組搭出介面,而公開主頁和店主控制檯都不硬編碼任何關於“餐廳是什麼”的知識。
模組契約
一個模組宣告一組固定的東西,應用據此拼出其餘一切。它給出一個 id;它認領的業務型別,決定這個模組是否適用於某家店;一個標籤和一個目錄標題;一個主行動號召,也就是顧客頁最先呈現的那個按鈕;以及一個目錄檢視——餐飲是菜單,住宿是房型,診所是服務專案,零售是商品。
另外四項宣告是可選的,而系統的價值正體現在那裡。模組可以宣告能力,它們會成為可分配給員工角色的新權限;控制檯磁貼,出現在店主的儀表盤網格里;一塊自己的控制檯介面;以及一段面向顧客的頁面區塊,注入店鋪的公開主頁。四項都不宣告的模組就是一個純目錄;四項都宣告的模組會同時重塑應用的兩側。
另外還有一套共享 UI 套件——主 CTA 按鈕、目錄行、標籤片、區塊標題和空狀態——模組應當基於它構建。這不是為了統一風格而統一風格:它是讓一個單獨編寫的模組看起來像應用的一部分、而不是一塊嵌入式掛件的原因。
四個核心模組就是業務型別
四個核心模組根本不是擴充套件;它們就是“業務型別”這件事本身的含義。餐飲認領 restaurant 和 cafe。住宿認領 stay、hotel、resort、apartment、condo 和 village——六個標籤、一個模組,因為共管公寓的出租和民宿的一晚,差別在措辭而不在機制。服務認領 service 和 clinic,其中診所變體把介面改稱預約、患者和療程,而不分叉程式碼。零售認領 retail。
因為它們是模組而不是一屏巨型介面裡的分支,餐飲模組的廚房顯示屏和選項組對一家酒店來說並不存在——不是藏在開關後面,不是被禁用,是不存在。一家店看到的介面面積,是它自稱是什麼的函式。
七個可安裝擴充套件,對任何型別都適用
核心模組之上是四個擴充套件,全部與業務型別無關。團隊權限最有意思,因為它是用其他模組搭出來的:它從每個已安裝模組宣告的能力構造出一個權限編輯器,所以裝上一個新模組,它的權限就自動出現在編輯器裡,不需要任何人去更新一份清單。
支付渠道加一塊用於配置受理渠道的控制檯磁貼,以及公開主頁上一份顧客可見的渠道清單——一個擴充套件透過兩個宣告槽同時寫到兩側。會員與訂閱引入顧客可以直接從店鋪主頁購買的方案。續費提醒處理會員和療程所產生的後續跟進。每一個都是按第三方將來會用的同一份契約寫成的、已經發布的第一方模組——這是一種刻意的自律,因為一份契約只有在它的作者也被它約束時才是真的。
按店安裝與解除安裝
擴充套件在店主控制檯裡的外掛商店中管理,安裝的作用域是單個商家。一位經營兩家店的店主可以只在其中一家裝會員功能,而兩個儀表盤會真的不一樣。
解除安裝在一個確認框後面,而確認框會說一句具體的話:資料不會被刪除。這比聽上去重要。人們在解除安裝按鈕前猶豫,是因為他們假設它是破壞性的,於是把用不上的模組一直留著,控制檯裡堆滿沒人點的磁貼。告訴他們什麼*不會*發生,才讓這個按鈕變得可用。解除安裝之後,擴充套件不再貢獻任何東西——沒有磁貼、角色編輯器裡沒有權限、公開主頁上沒有區塊——但它的記錄會在重灌後依然在。
它目前還不是什麼
第三方外掛沒有開放。外掛商店自己就這麼寫著,而不是靠一層空的“更多敬請期待”貨架去暗示別的。今天存在的是一套有真實契約的模組化架構、四個核心模組和七個照著它寫的第一方擴充套件,全部透過同一條註冊路徑載入。第三方提交是已宣告的下一步,不是一個已經上線的市場:沒有開發者門戶、沒有稽核佇列,也沒有公開的 SDK。我們這樣描述,是因為架構才是有意思的部分而且今天為真,而市場只是一句關於未來的宣告。
契約的檢驗標準是:一個完全照著它寫、不碰任何核心程式碼的模組——磁貼、能力和頁面區塊——能否表現得像應用的原生部分。四個做到了。把這件事對外開放,與其說是技術問題不如說是政策和稽核問題,而它還沒被解決。
為什麼是模組,而不是功能開關
功能開關關掉某樣東西,模組貢獻某樣東西。差別體現在權限編輯器上:用開關的話,得有人維護一份所有能力的總清單,並記得去擴充它;用契約的話,團隊權限擴充套件去問每個已安裝模組宣告瞭什麼,然後據此構建編輯器,那份清單就無法過期。同樣的模式也適用於儀表盤網格和公開主頁——它們都不列舉功能,它們都去問。
它同時限定了新增一條垂直業務的成本。要加一種 Korat 今天還不服務的業務型別,那是一個模組:宣告它認領的型別、一個目錄、一個 CTA,以及需要的那幾個可選槽位——不必去動控制檯、頁面渲染器或權限系統。這才是讓一個超級應用可控、而不是慢慢堆成一坨特例的原因。
這裡沒有第三方外掛市場。今天所有可安裝的東西都是第一方的,應用裡的商店也這麼寫。第三方提交是已宣告的下一步——目前還沒有開發者門戶,也沒有可供構建的公開 SDK。
外掛程式碼目前仍然打包在 APK 裡,而不是按外掛在使用時載入。這是一個已知的限制,也是把商店向專案之外的人開放的明顯前提。
- 必需宣告
- id · 認領的業務型別 · 標籤 · 目錄標題 · 主 CTA · 目錄檢視
- 可選宣告
- 能力 · 控制檯磁貼 · 控制檯介面 · 顧客頁區塊
- 核心模組
- 餐飲 · 住宿 · 服務 · 零售
- 擴充套件
- 團隊權限 · 支付渠道 · 會員與訂閱 · 續費提醒
- 安裝作用域
- 按店
- 解除安裝
- 在一個明說資料不會被刪除的確認框後面
- 第三方
- 未開放——只有第一方擴充套件
這裡的擴充套件全部是第一方的——排隊叫號、停車場這類模組並不是外部開發者寫的,所以也不存在一個第三方拿到你店裡資料的入口。
裝上之後哪位員工能看到它,和我的職場用的是同一套按人分配的權限。