在日常專案開發中，我們可能會遇到一些專案，它們的文案可能會不定期改變，多個頁面有相似之處，但是相同中又有不同，比如有的直播活動，策略邏輯沒變，改了獎品、背景圖和banner，也可以叫做換膚；也比如一些產品的官網，會不斷加一些子頁面，但是風格都是統一的，但會改變布局和文案。這個時候，做為技術，我們會思考如何能減少開發成本，避免改動一次文案替換乙個就跑一遍繁瑣的上線流程呢？大家一定能想到如果能把這些改動都做成可以配置的，那不就方便很多了麼？前陣子正好做了這樣場景的乙個專案，於是嘗試了下把頁面盡可能寫成可配置的。下面就簡單介紹下。
一、專案簡介：
專案是乙個官網專案，大部分都是靜態頁，分析需求，總結以下幾點：
二、整體思路
核心思想：需要配置的能配皆配。三、實現舉例
選單配置化
頂部選單舉例：
選單的效果如下圖，包含一級選單和二級選單。
選單配置json是這樣的
export
default
, footershow:
true
,// 控制頁尾是否展示
children:
[// 二級選單
, path:
'/product/audio-call'
,// 頁面路由
opentype:1,
// 是否新頁面開啟
icon:
'tab-p2.png'
,// 標題左側圖示}]
},]}
產品系列頁面配置
我們先來看一下設計稿
可以發現風格類似，每乙個產品介紹頁可以提出來。
我們再來看一下某乙個頁面的大圖。
再看下**，首先是產品頁，雖然頁面是多個，但是我們可以用一套**，這取決於我們將每個模組也進行了配置化。
通過定義modules的name屬性，每個模組載入對應的配置。
可以通過配置裡面直接寫style覆蓋當前樣式，也可以傳數值或者字串取頁面裡寫好的類名載入不同的樣式。
四、更進一步
到這裡，我們雖然已經實現了配置化，但卻是本地化的，我們修改乙個文案是可以直接改json，但是還是要走打包發布的流程。如何更進一步呢？這裡我們借助了公司內部前端架構組研發的pear配置平台，實現了json配置的線上配置。
然後我們引入對應的包和api呼叫線上資料。
import pearfetch from
"@***/pear-fetch"
;const configfetch =
newpearfetch()
;...
// 通過對應的id 拿到雲端的資料
const json =
await configfetch.
fetch()
;...
最後為了防止服務停止或者網路出錯，使用本地json配置兜底。
import
from
'@constant/pear'
;import
localdata
from
'../mock'
;async
getjsonconfig()
);this
.json =
await configfetch.
fetch()
;}catch
(err
)}
以上就是關於頁面配置化的一次簡單實踐，總體上提高了開發效率，尤其為後期維護節約了大量時間，甚至可以交給運營去維護配置，我們只需要發布之前把關即可。
頁面配置化確實值得嘗試，真的很香！
我是bigo前端，下期見。
記一次頁面優化及使用快取機制
一 使用html5的快取機制 1.先上規則 m.manifest cache manifest 2015 04 24 14 20 直接快取的檔案 cache templates specialty css style.css templates specialty js jquery.js temp...
一次頁面請求過程
很早之前就想寫一篇關於頁面請求整個過程的文章。當然，這樣的文章網上到處都是。而且自己寫的並沒有比別人好，那為什麼還要寫那。人都是善忘的動物，寫下來主要是作為備忘，同時鍛鍊下自己的表達能力。畢竟能把乙個問題講明白才能說明真正的懂了。詳細的報文分析可以參考 http權威指南 這裡不做贅述。如圖1，實際上...
一次元件化的實踐
更新 1.mvvm 可以將網路層轉移到viewmodel 層中，這樣就不需要將網路層抽離了，因為本來就沒和 控制器耦合。2.每次使用蜂巢的時候 控制器一定要實現 服務的協議，不然蜂巢會崩，還很難找到原因 3.蜂巢方案 雖然分離了控制器業務的耦合，但是引入了protocol 協議的耦合。同時需要維護 ...