秒殺支付寶雲鳳蝶,終極的移動端搭建系統多是這樣的

我們先來看一個頁面:頁面地址。這個頁面的搭建上線,我只花了5分鐘。固然這是由於我不須要考慮任何設計和業務,只是想把功能展現給你們看,但我相信這應該能初步讓你們看到咱們系統的強大。若是要看線上頁面能夠看這裏:619大促前端

須要注意,這個頁面的每一個TAB下面展現的內容是不一樣的,同時第一個TAB下面的分類切換以後展現的內容也是不一樣的,而且某個TAB或者分類下面能夠有多個不一樣的內容。vue

做爲對比,你們能夠上支付寶的雲鳳蝶搭建系統試一下。咱們能夠明顯發現,雲鳳蝶提供的功能是不可能搭建出這麼複雜的頁面的。固然這裏舉例雲鳳蝶不是由於他是行業最好的,而是由於我找到比較明確的是這個,並且我有個朋友在支付寶跟我說裏面用得不少。另外支付寶畢竟技術環境行業領先(他們本身也是這麼說的),因此相對仍是有點表明性的。react

這是咱們的搭建系統的第一個亮點:內容可嵌套(或者叫組件嵌套)。這是咱們系統設計之初就考慮進去的基礎能力,這不只僅須要在編輯的時候進行支持,同時在頁面運行層面上也是必須在基礎層就支持的。npm

搭建系統

早晚有一天,你看到的網頁,可能並非一幫叫作 前端開發工程師 寫出來的,而是任何一我的都能隨意建立的。---- by 薩姆胞弟json

相信你們或多或少都用過一些頁面搭建系統,古早的 Dreamware 也算是頁面搭建的早一批實踐者,不過他更偏向於UI設計,顯然對於業務功能沒什麼支持。這也能夠理解,放十年前不多能有前端工程師這一個職位的,大部分都是切圖仔,切完圖再讓後端去填入模板,來進行頁面訪問的數據裝填。後端

現年代的前端頁面搭建顯然跟那時候是不同的,因爲前端框架漸漸統一整個前端的開發標準,前端項目的開發模式也從之前的單個頁面,到如今的相似於移動APP同樣的單獨項目體系。頁面的渲染也基本不會通過後端服務,而是由前端在瀏覽器中計算並渲染。因此相較於叫 前端頁面 咱們更傾向於稱爲 前端應用瀏覽器

技術的變遷每每就會帶來產品形態的變化,基本上如今的互聯網公司都秉承着快速迭代成長的宗旨,因此無論處於哪一個階段的互聯網公司,只要有營銷需求,都會但願有一個頁面搭建系統,由於他能夠幫咱們解決不少的問題:前端框架

  • 運營產品自行建立頁面,高效
  • 無需開發人員介入,節流
  • 搭建者能夠根據本身需求作,省去了溝通成本以及可能的誤溝通致使最終產出不理想的問題

除去以上對於產出的提高外,由於搭建系統的組件相對統一穩定,也就省去了開發者在實現營銷頁面的過程當中可能犯的一些低級錯誤(畢竟人永遠是最大的變量)。前端工程師

綜上所述,搭建系統如今天然也是前端屆一個比較有意思和可以深刻的話題。架構

特點

說了這麼多,咱們的搭建系統又跟市面上的搭建系統又有什麼不同呢?在總結各類功能上的特色以前,我先來拋出一個概念的總結:

在設計之初,咱們就不以功能爲目的,而是創建在實現一個前端框架的特性上。

這句話怎麼理解呢?咱們的頁面前端是在vue框架上進行構建的,那麼vue做爲一個框架,可以符合咱們在前端開發中幾乎全部的能力需求,是由於什麼呢?我大體總結出幾點:

  • 組件化,經過props來抽象組件
  • 組件之間嵌套實現內容拼接
  • 經過 state => UI 的映射關係來完渲染和更新

由於對於大部分通用型的前端頁面來講,頁面就是各類元素的排列組合,加上一些樣式的不一樣。而頁面的主要更新,也是根據相關數據的更新來進行變化的,即使是事件的響應,很大程度上咱們也能夠視爲事件改變了一個咱們的state,而後再致使頁面UI的變化。這也是目前前端主流的框架奉行的實踐原則。

在這個基礎上,只要咱們搭建系統能準確得實現以上幾個基礎功能,那麼甚至能夠認爲咱們的搭建系統已經達到了和vue框架同級別的擴展能力。

固然你能夠說,vue的核心是響應式啊,確實是這樣,這是vue這個框架實現的核心技術。可是在以vue爲基礎搭建產品的過程當中,咱們並不會關心他的內部實現,而是更關心其暴露的API和能力,好比vue和react都有基於props來抽象組件的能力,咱們認爲這個能力是類似的,雖然他們內部的實現方式可謂天差地別。

在知道咱們的搭建系統的核心理念以後,咱們能夠來說講咱們的搭建系統到底有哪些特點功能:

  • 組件的嵌套
  • 組件間聯動

而在這基礎上,咱們能夠持有這些想象力:

  • 經過基礎組件拼接成一個新的組件,並讓其餘用戶可配置使用
  • 複雜的組件間交互聯動,好比某個組件內某個按鈕點擊了以後隱藏另一個組件

編輯界面

能夠看到在編輯tab的表單的時候,咱們能夠選擇每一個tab下使用的內容,能夠選擇其餘的組件。

不要小看這一點能力,一個基礎的能力能給產品帶來無限的想象力。

另外咱們其實已經作到了組件之間進行聯動的能力,只是在產品上尚未體現,緣由是產品尚未找到很好的表達方式讓用戶來使用這個功能。簡單來講就是運營童鞋沒法理解什麼叫組件間關聯,同時產品也暫時想不出什麼好的方式來下降學習成本,因此暫時未開放。但仍是上面那句話,基礎能力越多,產品的設計空間越大。

今天也就是來介紹一下這個產品,細節就再也不詳細講了,咱們的搭建系統的總體架構實際上是很是複雜的,包括:

  • 組件接入接口體系
  • 組件版本,runtime版本以及頁面版本維護方式
  • 一個相似於npm的組件發佈工具,並集成本地組件開發調試功能
  • 組件如何維護其props並在編輯的時候根據組件特性生成表單
  • 如何訪問每一個頁面
  • ...等等等一系列爲了提升可用性和效率的功能

這些之後會在慢慢分享,同時在開發期間實現了一套經過json-schema生成表單的工具,也即將開源,盡情期待。

最後最近還開發了一個預渲染的功能,進一步提高了首評體驗,減小了load js文件過程當中的白屏時間,頁面體驗上升了不止一個檔次。連接放在下面,你們能夠自行體驗:

推薦在手機端查看,畢竟沒有對PC端作優化。

原文地址

相關文章
相關標籤/搜索