摘要:基于的一套代碼支持多個項目的解決方案應用場景在端業務中,同樣的產品,客戶多多少少會要求一些定制化。那么,是否可以一套代碼支持多個項目呢前段時間,接了一個需求,技術選型是,用搭建的。在這個場景下研究了一下解決方案。
基于Vue-cli的一套代碼支持多個項目的解決方案 應用場景
在toB端業務中,同樣的產品,客戶多多少少會要求一些定制化。從皮膚,圖片,到一些小的功能的差異。
前端總是沖在最前面需要改的。如果改動不大的話,拉個分支有增加了維護的成本,分支拉多了,如果主干有一個問題相當于copy了n份,那個滋味簡直不要太酸爽。那么,是否可以一套代碼支持多個項目呢?
前段時間,接了一個需求,技術選型是VUE,用vue-cli搭建的。一套代碼需要支持10幾家客戶,每家的皮膚,功能都有一些小的差異,主體流程大致是一樣的。在這個場景下研究了一下解決方案。
思路總體的思路模塊化,然后在編譯的時候根據輸入命令直接組裝不同的模塊,打包出我們需要的頁面。
這個地方就有兩個問題:
1.如何劃分頁面,控制組件的顆粒度?
2.如何差異化編譯?
項目結構同樣一個頁面,有相同的部分,也有一些不一樣的部分。vue本身的組件化思想很容易讓我們想到把頁面拆分成組件,然后把公共的提取出來,差異化的分別處理。
項目總體結構 buildbuild結構中主要是webpack的一些腳本配置
configconfig文件主要是項目相關配置,我們常用的就是當端口沖突時配置監聽端口,打包輸出路徑及命名等
src源碼文件。
assets:靜態資源,一般放圖片,樣式等
less:樣式文件,這里分主題處理了
pages:頁面文件
router:路由
util:工具類
文件夾中是各個項目的自有的組件。components目錄下的是公共的組件
static靜態資源,不會被webpack編譯。一般放一下外部引用文件。
webpack打包配置 如何差異化編譯?1.cross-env使用環境變量。在編譯階段,根據編譯傳入的變量不同,編譯不同的組件。
首先,要改的是package.json的文件
"scripts": { "dev:gx": "cross-env BRANCH_ENV=gx node build/dev-server.js", "build:gx": "cross-env BRANCH_ENV=gx node build/build.js" },
這個時候我們編譯的時候輸入對應的命令 就可以傳入相應的環境變量。
eg:npm run dev:gx 會傳入BRANCH_ENV=gx。
2.把config/prod.env.js中注入這個環境變量
module.exports = { NODE_ENV: ""production"", API_PATH:"""", BRANCH_ENV: JSON.stringify(process.env.BRANCH_ENV) || ""base"", ignoreCsrfToken:""false"" }
3.webpack.base.conf.js
resolve: { extensions: ["", ".js", ".vue", ".json"], fallback: [path.join(__dirname, "../node_modules")], alias: { "vue$": "vue/dist/vue.common.js", "src": path.resolve(__dirname, "../src"), "assets": path.resolve(__dirname, "../src/assets/images/"+process.env.BRANCH_ENV), "components": path.resolve(__dirname, "../src/components"), "componentsDif": path.resolve(__dirname, "../src/components/"+process.env.BRANCH_ENV), } },
可以看的出,我們把編譯命令注入的環境變量在引入別名的時候用上了。比如說,假設我輸入的編譯命令是
npm run build:gx
這個時候
"assets": path.resolve(__dirname, "../src/assets/images/"+process.env.BRANCH_ENV) //等同于 "assets": path.resolve(__dirname, "../src/assets/images/gx")頁面引用 1.圖片引用
//根據編譯命令。圖片引用的是src/assets/images/gx/arrow.png background: url(~assets/btn_1.png) no-repeat;
ps:用別名的時候記得要加上~號
2.組件引用//公共組件 import ruleTitle from "components/RuleTitle" //差異化組件 import ruleContent from "componentsDif/RuleContent"總結
總而言之,核心思想就是跟進編譯命令傳入環境變量,利用環境變量和別名的配置來差異化打包。比較難的是如何控制組件的顆粒度,如何拆分組件,這個需要跟據需求的不同來實際定制。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/95784.html
摘要:可以使用或來安裝我用來重新嘗試一次對速度表示不理想的可以嘗試淘寶的不要過度依賴中可以寫成放哪都行,可以寫成可以寫成看到這個畫面,安裝完成了。 初步搭建腳手架 Tips 任何不錯的開源項目都有 project-cli 腳手架、我們用它生成往往能快速配制出最佳的、理想的腳手架 我通常使用 cli 生成項目骨架再在之基礎上進行個人修改。 什么是 CLI 命令行界面(英語:command-li...
摘要:可以使用或來安裝我用來重新嘗試一次對速度表示不理想的可以嘗試淘寶的不要過度依賴中可以寫成放哪都行,可以寫成可以寫成看到這個畫面,安裝完成了。 初步搭建腳手架 Tips 任何不錯的開源項目都有 project-cli 腳手架、我們用它生成往往能快速配制出最佳的、理想的腳手架 我通常使用 cli 生成項目骨架再在之基礎上進行個人修改。 什么是 CLI 命令行界面(英語:command-li...
閱讀 2061·2021-11-23 09:51
閱讀 2202·2021-09-29 09:34
閱讀 3694·2021-09-22 15:50
閱讀 3556·2021-09-22 15:23
閱讀 2559·2019-08-30 15:55
閱讀 699·2019-08-30 15:53
閱讀 3066·2019-08-29 17:09
閱讀 2624·2019-08-29 13:57