說好的教程終於來了,第一篇文章主要來講一說在開始寫業務代碼前的一些準備工做吧,但這裏不會教你webpack的基礎配置,熱更新怎麼作,webpack速度優化等等,有需求的請自行google。javascript
├── build // 構建相關 ├── config // 配置相關 ├── src // 源代碼 │ ├── api // 全部請求 │ ├── assets // 主題 字體等靜態資源 │ ├── components // 全局公用組件 │ ├── directive // 全局指令 │ ├── filtres // 全局filter │ ├── mock // mock數據 │ ├── router // 路由 │ ├── store // 全局store管理 │ ├── styles // 全局樣式 │ ├── utils // 全局公用方法 │ ├── view // view │ ├── App.vue // 入口頁面 │ └── main.js // 入口 加載組件 初始化等 ├── static // 第三方不打包資源 │ ├── jquery │ └── Tinymce // 富文本 ├── .babelrc // babel-loader 配置 ├── eslintrc.js // eslint 配置項 ├── .gitignore // git 忽略項 ├── favicon.ico // favicon圖標 ├── index.html // html模板 └── package.json // package.json
這裏來簡單講一下src文件html
簡單截取一下公司後臺項目,如今後臺大概有三十多個api模塊前端
如圖可見,模塊是不少的,並且隨着業務的迭代,模塊會愈來愈多。
因此這裏建議根據業務模塊來劃分views,而且將views 和 api 兩個模塊一一對應,方便維護.以下圖vue
如article模塊下放的都是文章相關的api,這樣無論項目怎麼累加,api和viede的維護仍是清晰的,固然也有一些全區公用的api模塊,如七牛upload,remoteSearch等等,這些單獨放置就行。java
這裏的components放置的都是全局公用的一些組件,如上傳組件,富文本等等。一些頁面級的組件建議仍是放在各自views文件下,如圖node
這裏我我的建議不要爲了用vuex而用vuex。就拿我司的後臺項目來講,它雖然比較龐大,二三十個業務模塊,十幾種權限,但業務之間的耦合度是很低的,文章模塊和評論模塊幾乎是倆個獨立的東西,因此根本沒有必要使用vuex來存儲data,每一個頁面裏存放本身的data就行。固然有些數據仍是須要用vuex來統一管理的,如登陸token,用戶信息,或者是一些全局我的偏好設置等,仍是用vuex管理更加的方便,具體固然仍是要結合本身的業務場景的。總之仍是那句話,不要爲了用vuex而用vuex!react
這裏是用vue-cli爲基礎模板構建的,若是你對這個有什麼疑惑請自行google,相關的配置介紹文章已經很詳細了,這裏就再也不展開了。簡單說一說須要注意到地方。jquery
管理後臺不一樣於前臺項目,會常常用到一些第三方插件,但有些插件是不得不依賴jquery的,如市面上好的富文本基都是依賴jquery的,因此乾脆就直接引入到項目中省事(gzip以後只有34kb,並且常年from cache,不要考慮那些吹毛求疵的大小問題,這幾kb和提升的開發效率根本不能比)。可是若是第三方庫的代碼中出現$.xxx或jQuery.xxx或window.jQuery或window.$則會直接報錯。要達到相似的效果,則須要使用webpack內置的ProvidePlugin插件,配置很簡單,只須要webpack
new webpack.ProvidePlugin({ $: 'jquery' , 'jQuery': 'jquery' })
這樣當webpack碰到require的第三方庫中出現全局的$、jQeury和window.jQuery時,就會使用node_module下jquery包export出來的東西了。ios
當項目逐漸變大以後,文件與文件直接的引用關係會很複雜,這時候就須要使用alias了。
有的人喜歡alias 指向src目錄下,再使用相對路徑找文件
resolve: {
alias: { '~': resolve(__dirname, 'src') } } //使用 import stickTop from '~/components/stickTop'
我習慣於
alias: {
'src': path.resolve(__dirname, '../src'), 'components': path.resolve(__dirname, '../src/components'), 'api': path.resolve(__dirname, '../src/api'), 'utils': path.resolve(__dirname, '../src/utils'), 'store': path.resolve(__dirname, '../src/store'), 'router': path.resolve(__dirname, '../src/router') } //使用 import stickTop from 'components/stickTop' import getArticle from 'api/article'
沒有好與壞對與錯,純看我的喜愛和團隊規範。
不論是多人合做仍是我的項目,代碼規範是很重要的。這樣作不只能夠很大程度地避免基本語法錯誤,也保證了代碼的可讀性。這所謂工欲善其事,必先利其器,我的推薦eslint+vscode來寫vue,絕對有種飛通常的感受。效果如圖:
每次保存,vscode就能標紅不符合eslint規則的地方,同時還會作一些簡單的自我修正。安裝步驟以下:
首先安裝eslint插件
安裝並配置完成 ESLint 後,咱們繼續回到 VSCode 進行擴展設置,依次點擊 文件 > 首選項 > 設置 打開 VSCode 配置文件,添加以下配置
"files.autoSave":"off", "eslint.validate": [ "javascript", "javascriptreact", "html", { "language": "vue", "autoFix": true } ], "eslint.options": { "plugins": ["html"] }
這樣每次保存的時候就能夠根據根目錄下.eslintrc.js你配置的eslint規則來檢查和作一些簡單的fix。這裏提供了一份我平時的eslint規則地址,都簡單寫上了註釋。每一個人和團隊都有本身的代碼規範,統一就行了,去打造一份屬於本身的eslint 規則上傳到npm吧,如餓了麼團隊的config,vue的config。
咱們常常遇到一些線上的bug,但測試環境很難模擬。其實能夠經過簡單的配置就能夠在本地調試線上環境。
這裏結合業務封裝了axios ,線上代碼
import axios from 'axios'; import { Message } from 'element-ui'; import store from '../store'; import router from '../router'; export default function _fetch(options) { return new Promise((resolve, reject) => { const instance = axios.create({ baseURL: process.env.BASE_API, //經過env環境變量切換api地址 // timeout: 2000, //請求超時時間 headers: { 'X-Token': store.getters.token }//後臺項目,每一個請求都須要token,判斷權限 }); instance(options) .then(response => { const res = response.data; //我司經過自定義code來判斷 如:code不等於20000就被試爲異常 if (res.code !== 20000) { console.log(options); // for debug Message({ message: res.message, type: 'error', duration: 5 * 1000 }); // 50014:Token 過時了 50012:其餘客戶端登陸了 50008:非法的token if (res.code === 50008 || res.code === 50014 || res.code === 50012) { Message({ message: res.message, type: 'error', duration: 5 * 1000 }); // 登出 store.dispatch('FedLogOut').then(() => { router.push({ path: '/login' }) }); } reject(res); } resolve(res); }) .catch(error => { Message({ message: '發生異常錯誤,請刷新頁面重試,或聯繫程序員', type: 'error', duration: 5 * 1000 }); console.log(error); // for debug reject(error); }); }); }
//使用 export function getInfo(token) { return _fetch({ url: '/user/info', method: 'get', params: { token } }); }
好比後臺項目,每個請求都是要帶token來驗證權限的,這樣封裝如下的話咱們就不用每一個請求都手動來塞token,或者來作異常處理,一勞永逸。
並且由於咱們的api是更具env環境變量動態切換的,若是之後線上出現了bug,咱們只要將配置dev.env.js
module.exports = {
NODE_ENV: '"development"', BASE_API: '"https://api-dev"', //修改成'"https://api-prod"'就好了 APP_ORIGIN: '"https://wallstreetcn.com"' //爲公司打個廣告 pc站爲vue+ssr }
媽媽不再用擔憂我調試線上bug了。
固然這裏只是簡單舉了個例子,axios還能夠執行多個併發請求,攔截器什麼的,你們自行去研究吧。
vue-cli 默認只提供了dev和prod兩種環境。但其實正真的開發流程可能還會多一個sit環境,就是所謂的測試環境。因此咱們就要簡單的修改一下代碼。其實很簡單就是設置不一樣的環境變量
"build:prod": "NODE_ENV=production node build/build.js", "build:sit": "NODE_ENV=sit node build/build.js",
以後在代碼裏自行判斷,想幹就幹啥
var env = process.env.NODE_ENV === 'production' ? config.build.prodEnv : config.build.sitEnv
新版的vue-cli也內置了webpack-bundle-analyzer 一個模塊分析的東西,至關的好用。使用方法也很簡單,和以前同樣封裝一個npm script 就能夠。
//package.json "build:sit-preview": "NODE_ENV=sit npm_config_preview=true npm_config_report=true node build/build.js" //以後經過process.env.npm_config_report來判斷是否來啓用webpack-bundle-analyzer var BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin webpackConfig.plugins.push(new BundleAnalyzerPlugin())
效果圖
webpack-bundle-analyzer這個插件仍是頗有用的,對後期的代碼優化什麼的,最重要的是它夠裝逼~
每一個公司都有本身一套的開發流程,沒有絕對的好與壞。這裏我來說講我司的先後端開發流程。
首先先後端交互不可避免的就會遇到跨域問題,我司如今全是用cors來解決的,若是你司後端嫌麻煩不願配置的話,dev環境也能夠經過
webpack-dev-server的proxy來解決,開發環境用nginx反代理一下就行了,具體配置這裏就不展開了。
其實你們也知道,平時的開發中交流成本佔據了咱們很大一部分時間,但先後端若是有一個好的協做方式的話能解決不少時間。我司開發流程都是先後端和產品討論項目,以後 後端mock api 生成好文檔,咱們前端纔是對接接口的。這裏推薦一個文檔生成器swagger
swagger是一個REST APIs文檔生成工具,能夠在許多不一樣的平臺上從代碼註釋中自動生成,開源,支持大部分語言,社區好,總之就是一個神奇,給你們透露一下我司的api 文檔(swagger自動生成,ui忽略)
url地址,須要傳是沒參數,須要的傳參類型,返回的數據格式什麼都一清二楚了,咱們大前端終於不用再看後端的臉色了~
若是後端不願來幫你mock數據的話,前端本身來mock也是很簡單的。你可使用mock server 或者使用mockjs+rap也是很方便的。
element-ui 默認的icon不是不少,這裏要安利一波阿里的iconfont簡直是神器,不論是公司項目仍是我的項目都在使用。它提供了png,ai,svg三種格式,同時使用也支持unicode,font-class,symbol三種方式。因爲是管理後臺對兼容性要求不高,樓主平時都喜歡用symbol,就是用svg的方式引入iconfont.js,以後就能歡快的去選icon了,還能本身上傳icon。曬一波我司後臺的圖標(都是樓主本身發揮的)。
different router the same component vue。真實的業務場景中,這種狀況不少。好比
我建立和編輯的頁面使用的是同一個component,默認狀況下當這兩個頁面切換時並不會觸發vue的created或者mounted鉤子,官方說你能夠經過watch $route的變化來作處理,但其實說真的仍是蠻麻煩的。後來發現其實能夠簡單的在 router-view上加上一個惟一的key,來保證路由切換時都會從新渲染觸發鉤子了。這樣簡單的多了。
<router-view :key="key"></router-view> computed: { key() { return this.$route.name !== undefined? this.$route.name + +new Date(): this.$route + +new Date() } }
有些人會以爲如今構建是否是有點慢,我司如今技術棧是容器服務,後臺項目會把dist文件夾裏的東西都會打包成一個docker鏡像,基本步驟爲
npm install
npm run build:prod 加打包鏡像,一共是耗時以下
仍是屬於能接受時間的範圍。
主站PC站基於nodejs、Vue實現服務端渲染,因此不只須要依賴nodejs,並且須要利用pm2進行nodejs生命週期的管理。爲了加速線上鏡像構建的速度,咱們利用taobao源 https://registry.npm.taobao.org 進行加速, 而且將一些常見的npm依賴打入了基礎鏡像,避免每次都須要從新下載。
這裏注意下 建議不要使用cnpm install或者update 它的包都是一個link,反正會有各類詭異的bug,這裏建議這樣使用
npm install --registry=https://registry.npm.taobao.org
若是你以爲慢仍是有可優化的空間如使用webpack dll 或者把那些第三方vendor單獨打包 external出去,或者我司如今用的是http2 可使用AggressiveSplittingPlugin等等,這裏有需求的能夠自行優化。
常規佔坑,這裏是手摸手,帶你用vue擼後臺 系列一,下一篇會主要講講搭建用戶系統,二次登陸,權限驗證這些東西,有時間的話,還會寫一下基於element-ui動態換膚的實現方案。或者你們能夠留言說說想要看一些什麼。