背景
在日常項目開發中，我們可能會遇到一些項目，它們的文案可能會不定期改變，多個頁面有相似之處，但是相同中又有不同，比如有的直播活動，策略邏輯沒變，改了獎品、背景圖和banner，也可以叫做換膚；也比如一些產品的官網，會不斷加一些子頁面，但是風格都是統一的，但會改變佈局和文案。這個時候，做爲技術，我們會思考如何能減少開發成本，避免改動一次文案替換一個圖片就跑一遍繁瑣的上線流程呢？大家一定能想到如果能把這些改動都做成可以配置的，那不就方便很多了麼？前陣子正好做了這樣場景的一個項目，於是嘗試了下把頁面儘可能寫成可配置的。下面就簡單介紹下。
一、項目簡介：
項目是一個官網項目，大部分都是靜態頁，分析需求，總結以下幾點：
- 子頁面有多個，UI模板類似
- 部分頁面會經常改動
- 後期可能增加新頁面，但是風格相同，基本佈局不變
二、整體思路
核心思想：需要配置的能配皆配。
對於整個項目，可以配置的有菜單欄、某個頁面包含的不同模塊
對於單個頁面，可以配置的主要是圖片、文案、樣式、鏈接等
三、實現舉例
菜單配置化
頂部菜單舉例：
菜單的效果如下圖，包含一級菜單和二級菜單
菜單配置json是這樣的
export default {
menus: [
{
title: { // 一級菜單標題
default: '產品', // 默認文案
langKey: 'tabLang001', // 多語言文案
},
footerShow: true, // 控制頁腳是否展示
children: [ // 二級菜單
{
title: { // 二級菜單標題
default: '實時音頻互動',
langKey: 'tabLang002',
},
path: '/product/audio-call', // 頁面路由
openType: 1, // 是否新頁面打開
icon: 'tab-p2.png', // 標題左側圖標
}
]
},
]
}
最外層寫成數組，方便拓展，引入賦值後，根據我們的需要進行遍歷，結合判斷具體用途的屬性是否存在實現每一項個性化的配置。
產品系列頁面配置舉例：
我們先來看一下設計稿
可以發現風格類似，每一個產品介紹頁可以提出來
我們再來看一下某一個頁面的大圖
再看下代碼，首先是產品頁，雖然頁面是多個，但是我們可以用一套代碼，這取決於我們將每個模塊也進行了配置化
通過定義modules的name屬性，每個模塊加載對應的配置
可以通過配置裏面直接寫style覆蓋當前樣式，也可以傳數值或者字符串取頁面裏寫好的類名加載不同的樣式。
更進一步
到這裏，我們雖然已經實現了配置化，但卻是本地化的，我們修改一個文案是可以直接改json，但是還是要走打包發佈的流程。如何更進一步呢？這裏我們藉助了公司內部前端架構組研發的pear配置平臺，實現了json配置的線上配置。
首先我們在平臺創建一個配置文件，然後把本地配置數據複製進去，發佈，這樣我們就有了一個在線的配置文件。
然後我們引入對應的包和api調用線上數據
import pearFetch from "@xxx/pear-fetch";
const configFetch = new pearFetch({
bizType: "xxx",
pearEnv: env === "prod" ? "prod" : "gray",
});
...
// 通過對應的id 拿到雲端的數據
const json = await configFetch.fetch({ id: xxxxxx });
...
根據json中約定的key，比如這裏是以路由爲key，將數據分發到各個頁面。
最後爲了防止服務停止或者網絡出錯，使用本地json配置兜底，類似這樣
import { PEAR_ID } from '@constant/pear';
import LOCALDATA from '../mock';
async getJsonConfig() {
try {
const configFetch = new pearFetch({
bizType: 'xxx',
pearEnv: this.nodeEnv === 'production' ? 'prod' : 'gray',
});
this.json = await configFetch.fetch({ id: PEAR_ID });
} catch (err) {
// 本地數據兜底
this.json = LOCALDATA;
}
}
pear平臺提供了發佈配置和修改配置的能力，這樣如果有文案需要修改，就可以直接在雲端修改後發佈，不再需要走繁瑣的項目發佈流程了。優點是能快速更新線上。當然之後爲了保持文案同步，建議把雲端最新的配置複製到本地。隨之後版本一起升級。
結語
以上就是關於頁面配置化的一次簡單實踐，總體上提高了開發效率，尤其爲後期維護節約了大量時間，甚至可以交給運營去維護配置，我們只需要發佈之前把關即可。
頁面配置化確實值得嘗試，真的很香！
具體哪些場景更適合？
如何實現更高的靈活性但又不會過度設計浪費開發時間？
這些還需要更深的思考和實踐。也歡迎大家討論補充！