整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
整項目地址：vue-element-admin
https://github.com/PanJiaChen/vue-element-admin
做這個 vueAdmin-template 的主要原因是: vue-element-admin 這個項目的初衷是一個 vue 的管理后臺集成方案，把平時用到的一些組件或者經(jīng)驗分享給大家，同時它也在不斷的維護(hù)和拓展中，比如最近重構(gòu)了dashboard，加入了全屏功能，新增了 tabs-view 等等。所以項目會越來越復(fù)雜，不太適合很多初用 vue 的同學(xué)來構(gòu)建后臺。所以就寫了這個基礎(chǔ)模板，它沒有復(fù)雜的功能，只包含了一個后臺需要最基礎(chǔ)的東西。 vueAdmin-template 主要是基于vue-cli webpack模板為基礎(chǔ)開發(fā)的，引入了如下dependencies:
該項目只做了一個管理后臺需要極簡的功能，封裝了axios請求，支持無限層級路由，動態(tài)權(quán)限和動態(tài)側(cè)邊欄。 如果需要更多復(fù)雜的功能可以參考 vue-element-admin，若還有不足，歡迎提issue或者pr。下文會簡單說一下用該模板需要注意的地方。
路由懶加載應(yīng)該是寫大一點(diǎn)的項目都會用的一個功能，只有在使用這個component的時候才會加載這個相應(yīng)的組件，這樣寫大大減少了初始頁面 js 的大小并且能更好的利用瀏覽器的緩存。
const Foo = resolve => require(['./Foo.vue'], resolve)
//或者
const Foo = () => import('./Foo');
復(fù)制代碼在懶加載頁面不多的情況下一切是那么的美好，但我司后臺業(yè)務(wù)在不斷地迭代，現(xiàn)在項目近百個路由，這時候使用路由懶加載在開發(fā)模式下就是一件痛苦的事情了，隨手改一行代碼熱更新都是要6000ms+的，這怎么能忍。樓主整整花了一天多的時間找原因，能webpack優(yōu)化的方法都用了,什么 dll, HappyPack 等方法都是過了，但提升的效果都不是很明顯，正好那段時間出了 webpack3 樓主也升級了，編譯速度也得到了很大幅度的提升，不過也要2000ms+。后來經(jīng)過大神 @jzlxiaohei 的指點(diǎn)發(fā)現(xiàn)原來是路由懶加載搞得鬼，樓主猜測可能是異步加載導(dǎo)致 webpack 每次的 cache 失效了，所以每次的rebuild 才會這么的慢。找到了原因我們就可以對癥下藥了，我們就自己封裝了一個_import()的方法，只有在正式環(huán)境下才使用懶加載。這樣解決了困擾多事的rebuild慢問題。代碼
const _import = require('./_import_' + process.env.NODE_ENV);
const Foo = _import('Foo');
復(fù)制代碼整整比原來6000ms快了十多倍，我終于又能愉快的開發(fā)了。
在手摸手，帶你用vue擼后臺 系列二(登錄權(quán)限篇)這章中其實(shí)已經(jīng)詳細(xì)介紹過了。該項目中權(quán)限的實(shí)現(xiàn)方式是：通過獲取當(dāng)前用戶的權(quán)限去比對路由表，生成當(dāng)前用戶具的權(quán)限可訪問的路由表，通過router.addRoutes動態(tài)掛載到router上。 但其實(shí)很多公司的業(yè)務(wù)邏輯可能不是這樣的，舉一個例子來說，很多公司的需求是每個頁面的權(quán)限是動態(tài)配置的，不像本項目中是寫死預(yù)設(shè)的。但其實(shí)原理是相同的。如這個例子，你可以在后臺通過一個tree控件或者其它展現(xiàn)形式給每一個頁面動態(tài)配置權(quán)限，之后將這份路由表存儲到后端。當(dāng)用戶登錄后根據(jù)role，后端返回一個相應(yīng)的路由表或者前端去請求之前存儲的路由表動態(tài)生成可訪問頁面，之后就是router.addRoutes動態(tài)掛載到router上，你會發(fā)現(xiàn)原來是相同的，萬變不離其宗。
側(cè)邊欄:本項目里的側(cè)邊欄是根據(jù) router.js 配置的路由并且根據(jù)權(quán)限動態(tài)生成的，這樣就省去了寫一遍路由還要再手動寫側(cè)邊欄這種麻煩事，同是使用了遞歸組件，這樣不管你路由多少級嵌套，都能愉快的顯示了。權(quán)限驗證那里也做了遞歸的處理。
面包屑:本項目中也封裝了一個面包屑導(dǎo)航，它也是通過watch $route動態(tài)生成的。代碼
由于側(cè)邊欄導(dǎo)航和面包屑亦或是權(quán)限，你會發(fā)現(xiàn)其實(shí)都是和router密切相關(guān)的，所以基于vue-router路由信息對象上做了一下小小的拓展，自定義了一些屬性
icon : the icon show in the sidebar
element-ui自帶的圖標(biāo)不是很豐富，但管理后臺圖標(biāo)的定制性又很強(qiáng)。這里只給大家推薦使用阿里的 iconfont ，簡單好用又方便管理。本項目中已經(jīng)嵌入了一些 iconfont 作為例子，大家可以自行替換。 這里來簡單介紹一下 iconfont 的使用方式。首先注冊好 iconfont 賬號之后，可以在我的項目中管理自己的 iconfont 。我司所有的項目都是用這個管理的，真心推薦使用。
創(chuàng)建好圖標(biāo)庫后如果有更新替換也很方便，這里我使用了 Symbol 的方式引入，這里還有unicode，font-class的引入方式，有興趣的可以自行研究。 之后我們點(diǎn)擊下載 Symbol，會發(fā)現(xiàn)有如下這些文件，我們只要關(guān)心iconfont.js就可以了
我們將它替換項目中的 iconfont.js 就可以了。本項目中也封裝了一個svg component 方便大家使用。
<icon-svg icon-class="填入你需要的iconfont名字就能使用了"></icon-svg>
復(fù)制代碼每個項目都需要有一個屬于自己的favicon。
其實(shí)實(shí)現(xiàn)起來非常的方便，我們主需要借助html-webpack-plugin
//webpack config
function resolveApp(relativePath) {
return path.resolve(relativePath);
}
new HtmlWebpackPlugin({
filename: config.build.index,
template: 'index.html',
inject: true,
favicon: resolveApp('favicon.ico')
}),
復(fù)制代碼你只要將本項目跟目錄下的favicon.ico文件替換為你想要的圖標(biāo)即可。
vue cli 默認(rèn)提供了standard和airbnb 兩種 lint 規(guī)范，說真的一個j檢查校驗的太松一個又太緊，而且每個團(tuán)隊的 lint 規(guī)范又是不同的，所以樓主干脆在項目里把大部分常用的 lint 規(guī)范都列舉了出來并寫上了注釋方便大家修改代碼地址，大家也可以把自己的規(guī)范上傳到npm，像 vue 一樣 vue-eslint-config。配置 eslint 對多人協(xié)作的項目有很大的好處,同時配置好lint 在加 ide 的 lint 插件寫代碼簡直要起飛。相關(guān)配置可見第一篇教程。
相信大部分 vue 的項目都是基于 vue-cli 來開發(fā)的，不過畢竟每個人需求都是不太一樣的，需要自定義一些的東西。就比如拿 postcss 來說 vue-cli 有一個小坑，它默認(rèn) autoprefixer 只會對通過 vue-loader 引入的樣式有作用，換而言之也就是 .vue 文件里面的 css autoprefixer 才會效果。相關(guān)問題issues/544,issues/600。解決方案也很簡單粗暴
//app.vue
<style lang="scss">
@import './styles/index.scss'; // 全局自定義的css樣式
</style>
復(fù)制代碼你在 .vue 文件中引入你要的樣式就可以了，或者你可以改變 vue-cli的文件在 css-loader 前面在加一個 postcss-loader，在前面的issue地址中已經(jīng)給出了解決方案。 這里再來說一下 postcss 的配置問題，新版的vue-cli webpack 模板 inti 之后跟目錄下默認(rèn)有一個.postcssrc.js 。vue-loader 的 postcss 會默認(rèn)讀取這個文件的里的配置項，所以在這里直接改配置文件就可以了。配置和postcss是一樣的。
//.postcssrc.js
module.exports = {
"plugins": {
// to edit target browsers: use "browserlist" field in package.json
"autoprefixer": {}
}
}
//package.json
"browserslist": [
"> 1%",
"last 2 versions",
"not ie <= 8"
]
復(fù)制代碼如上代碼所述，autoprefixe r回去讀取 package.json 下 browserslist的配置文件
本項目暫時沒有兼容性需求，如有兼容性需求可自行使用babel-polyfill。 在Node/Browserify/webpack中使用
npm install --save babel-polyfill //下載依賴
復(fù)制代碼在入口文件中引入
import 'babel-polyfill';
// 或者
require('babel-polyfill');//es6
復(fù)制代碼在webpack.config.js中加入babel-polyfill到你的入口數(shù)組：
module.exports = {
entry:["babel-polyfill","./app/js"]
}
復(fù)制代碼具體可參考 link
或者更簡單暴力 polyfill.io 使用它給的一個 cdn 地址，引入這段js之后它會自動判斷游覽器，加載缺少的那部分 polyfill，但國內(nèi)速度肯能不行，大家可以自己搭 cdn。
樓主 vue 群里的小伙伴們問的最多的問題還是關(guān)于跨域的，其實(shí)跨域問題真的不是一個很難解決的問題。這里我來簡單總結(jié)一下我推薦的幾種跨域解決方案。
開發(fā)環(huán)境 生成環(huán)境 cors cors proxy nginx
這里我只推薦這兩種方式跨域，其它的跨域方式都很多，但真心主流的也就這兩種方式。
vue-element-admin 由于是一個純前端個人項目,所以所以的數(shù)據(jù)都是用mockjs生成的,它的原理是:攔截了所有的請求并代理到本地模擬數(shù)據(jù)，所以 network 中沒有任何的請求發(fā)出。不過這并不符合實(shí)際業(yè)務(wù)開發(fā)中的場景，所以這個項目中使用了前不久剛出的 easy-mock，支持跨域，mockjs 的語法，支持Swagger 這幾點(diǎn)還是挺不錯的。相關(guān)文章
線上或者測試環(huán)境接口的 base_url 不一樣是很長見得需求，或者你在本地用了如 easy-mock 這種模擬數(shù)據(jù)到線上環(huán)境你想用自己公司生產(chǎn)環(huán)境的數(shù)據(jù)，這些需求都可以簡單的通過用 baseurl 來解決。首先我們在config/下有dev.env.js和prod.env.js這兩個配置文件。用它來區(qū)分不同環(huán)境的配置參數(shù)。
//dev.env.js
module.exports = {
NODE_ENV: '"development"',
BASE_API: '"https://easy-mock.com/mock/5950a2419adc231f356a6636/vue-admin"',
}
//prod.env.js
module.exports = {
NODE_ENV: '"production"',
BASE_API: '"https://prod-xxx"',
}
復(fù)制代碼同時本項目封裝了axios攔截器，方便大家使用，大家也可根據(jù)自己的業(yè)務(wù)自行修改。
import axios from 'axios';
import { Message } from 'element-ui';
import store from '../store';
// 創(chuàng)建axios實(shí)例
const service = axios.create({
baseURL: process.env.BASE_API, // api的base_url 讀取config配置文件
timeout: 5000 // 請求超時時間
});
// request攔截器
service.interceptors.request.use(config => {
if (store.getters.token) {
config.headers['X-Token'] = store.getters.token; // 讓每個請求攜帶自定義token 請根據(jù)實(shí)際情況自行修改
}
return config;
}, error => {
// Do something with request error
console.log(error); // for debug
Promise.reject(error);
})
// respone攔截器
service.interceptors.response.use(
response => {
/**
* code為非20000是拋錯 可結(jié)合自己業(yè)務(wù)進(jìn)行修改
*/
const res = response.data;
if (res.code !== 20000) {
Message({
message: res.data,
type: 'error',
duration: 5 * 1000
});
// 50008:非法的token; 50012:其他客戶端登錄了; 50014:Token 過期了;
if (res.code === 50008 || res.code === 50012 || res.code === 50014) {
MessageBox.confirm('你已被登出，可以取消繼續(xù)留在該頁面，或者重新登錄', '確定登出', {
confirmButtonText: '重新登錄',
cancelButtonText: '取消',
type: 'warning'
}).then(() => {
store.dispatch('FedLogOut').then(() => {
location.reload();// 為了重新實(shí)例化vue-router對象 避免bug
});
})
}
return Promise.reject(error);
} else {
return response.data;
}
},
error => {
console.log('err' + error);// for debug
Message({
message: error.message,
type: 'error',
duration: 5 * 1000
});
return Promise.reject(error);
}
)
export default service;
復(fù)制代碼由于axios每一個都是一個實(shí)例，你的請求都是基于這個實(shí)例來的，所以所以配置的參數(shù)屬性都繼承了下來.
//api.xxx.js
import fetch from '@/utils/fetch';
export function getInfo(token) {
return fetch({
url: '/user/info',
method: 'get',
params: { token }
});
}
//你可以直接這樣使用，之前攔截器寫的東西都是生效的，
//它自動會有一個你之前配置的baseURL,
//但你說我這個請求baseURL和其它的不同,
//這也是很方便的，你可以字請求內(nèi)部修改，
//它會自動覆蓋你在創(chuàng)建實(shí)例時候?qū)懙膮?shù)如
export function getInfo(token) {
return fetch({
baseURL: https://api2-xxxx.com
url: '/user/info',
method: 'get',
params: { token }
});
}
復(fù)制代碼這篇文章主要是介紹了 vueAdmin 做了哪些事情，希望大家如果有后臺新項目要開發(fā)，建議基于 vue-admin-template 來開發(fā)，而 vue-element-admin 更多的是用來當(dāng)做一個集成方案，你要什么功能就去里面找拿來用，因為兩者的基礎(chǔ)架構(gòu)是一樣的，所以復(fù)用成本也很低。
知道早期的開發(fā)中，前后端是不分離的嗎？那么后來它們又為什么要“分家”呢？分離后又有什么好處呢？
在前面一篇文章中，產(chǎn)品汪搞懂了前后端的工作分工。但是了解過程中，一個程序猿哥哥不經(jīng)意間的一句話：“現(xiàn)在都是前后端分離的”，讓小汪感到納悶了，以前難道前后端不分離的么？于是小汪就繼續(xù)深究起來。
在十幾年前，前端的地位其實(shí)相對于后端并不那么強(qiáng)勢，以下是一種經(jīng)典的編程框架。
MVC：Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設(shè)計典范，用一種業(yè)務(wù)邏輯、數(shù)據(jù)、界面顯示分離的方法組織代碼。
有意思的事情出現(xiàn)了，內(nèi)容是傳給用戶的，前端并不是直接接觸用戶的！前端只是提供了個樣式模板，由后端把內(nèi)容嵌入進(jìn)入，再由后端直接傳給用戶。
這個時候，前端的編程要各種順著后端哥哥的心意，而且前端要是出bug了，還得拉上后端一起研究，誰讓你往我的模板里插了內(nèi)容，出了幺蛾子你就得負(fù)責(zé)到底。
這個時期前后端高度耦合，從編程環(huán)境、到開發(fā)調(diào)試，都必須“在一起”，對于前端來說，其實(shí)自主權(quán)就不高，對后端來說，也要懂一些前端的知識。
于是前端程序猿對后端程序猿說，要不……你只管你的業(yè)務(wù)和數(shù)據(jù)，把結(jié)果給我，我來負(fù)責(zé)組裝與呈現(xiàn)，這樣大家都輕松些。于是前后端就分離了。
前后端分離帶來的好處：
（1）編程更輕松
前后端分離之后，后端更專注于實(shí)現(xiàn)業(yè)務(wù)邏輯，形成一套標(biāo)準(zhǔn)化的“API接口”，例如需要創(chuàng)建商品，前端將商品信息傳給后端創(chuàng)建商品的接口，后端就會完成商品的創(chuàng)建，并返回創(chuàng)建結(jié)果。如果前端給的創(chuàng)建商品信息缺了標(biāo)題或者價格，后端還能返回創(chuàng)建失敗的結(jié)果，并且提示缺失了哪些信息等。
前端除了負(fù)責(zé)界面樣式和交互，還接管了獲取和展示數(shù)據(jù)的權(quán)利，從此前端開發(fā)就自由多了，如果遇上bug，也能很輕松定位到是前端還是后臺的事情。
（2）更高的可復(fù)用性
前后端分離，更是順應(yīng)了互聯(lián)網(wǎng)發(fā)展多樣化的潮流。后端通過提供一系列可以實(shí)現(xiàn)不同業(yè)務(wù)功能的接口，就可以讓不同的前端、甚至外部系統(tǒng)過來對接。
這樣方便了公司不斷推廣自己的產(chǎn)品，今天推出手機(jī)網(wǎng)頁版、明天推出APP版、后天推出小程序版本等。而后端只需要提供一次接口，無需每增加一類客戶端，后端就要新寫過。
用戶訪問網(wǎng)站的過程小知識：
但是久而久之，前后端分離在web網(wǎng)頁上也遇到了一些問題，最明顯的是以下兩點(diǎn)：
前后端分離為用戶設(shè)備帶來的影響，可以通過“換臺新手機(jī)”、“換臺新電腦”解決，但是搜索引擎爬不到網(wǎng)頁的數(shù)據(jù)，對很多重度依賴搜索引擎流量的產(chǎn)品來講，打擊可就大了。
例如你需要找一個菜譜的時候，可能會在百度搜索“芥藍(lán)怎么炒好吃？”，然后再從搜索結(jié)果里面訪問各種美食網(wǎng)站。又或者你想去哪里玩，就會在百度搜索“土耳其旅游攻略”等等。對于這類重搜索引擎流量的網(wǎng)站而言，如果爬蟲爬不到自己的數(shù)據(jù)，客流損失就比較嚴(yán)重。
考慮到上訴問題，聰明的網(wǎng)頁前端程序猿就想到了一個新的辦法，那我們先把后臺的數(shù)據(jù)跟HTML內(nèi)容整合好，再呈現(xiàn)給用戶吧，得力于一種叫做Node.JS的、可以使用網(wǎng)頁前端熟悉的JavaScript編程的工具，于是有了2.0版本的前后端分離。
前端程序猿跟服務(wù)器上的后端說，讓一讓，給我騰個地兒，然后把Node.JS放在了服務(wù)器上。等用戶或者爬蟲需要訪問網(wǎng)頁時，這個運(yùn)行在服務(wù)器上的程序，先請求后端獲得數(shù)據(jù)，并整合到HTML中，然后再返回給用戶。
這樣一來，用戶的設(shè)備就少了JavaScript多次請求后端的煩惱，加快了運(yùn)行速度，而爬蟲也可以爬取到填充好內(nèi)容的HTML網(wǎng)頁了。
看到這里，小汪就想，這么一來，用戶體驗、爬蟲的問題確實(shí)解決了，但是讓本來本該發(fā)生在用戶瀏覽器上的事情，都在服務(wù)器上做了嘛，如果訪問量大的話，咱服務(wù)器的壓力不就很大了？
前端程序猿哥哥呵呵一笑，其實(shí)不然，你想想，很多用戶都是在訪問同一個網(wǎng)頁，看同一個商品、讀同一篇文章，這些請求，要是服務(wù)器的前端就請求后臺一次，然后把整合好的HTML保存起來，下次再有人再來訪問，就把這個生成好的HTML展示給用戶，這樣不就服務(wù)器輕松了、用戶訪問也快了么！
小汪又問了，那咋們頁面多了，不就要每個頁面都保存一份HTML文件么，服務(wù)器儲存的空間不就越來越少了么？
前端程序猿哥哥繼續(xù)答道：久而久之，HTML文件在服務(wù)器積累多了，就把好久都沒人訪問的HTML刪了，給其他新保存的HTML文件讓位置，通過“緩存”技術(shù)，讓服務(wù)器永葆活力。
小汪恍然大悟，原來這就是緩存啊！這下子，小汪終于明白了前后端分離是什么回事，以及為什么要前后端分離。
現(xiàn)在隨著很多大型產(chǎn)品的形成、獨(dú)立運(yùn)行，新的“信息孤島”正在形成。例如微信的公眾號-小程序-朋友圈-圈子，然后通過搜一搜進(jìn)行統(tǒng)一搜索，內(nèi)部造血，而不再依賴傳統(tǒng)的搜索引擎為他引流。
又例如淘寶，很多年前就拒絕了讓百度爬蟲爬取他的商品信息，只允許在淘寶內(nèi)進(jìn)行搜索。你在百度上搜不到淘寶的商品，在微信上也找不淘寶的任何信息、無法訪問淘寶任何的鏈接，如果你要淘寶購物，就只能去淘寶網(wǎng)站或者下載淘寶APP。新的互聯(lián)網(wǎng)格局的形成，肯定會進(jìn)一步影響著前后端的關(guān)系。
本文由 @iCheer 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于CC0協(xié)議。
為了豐富 Naive Admin 生態(tài)，近期我們一直在精雕細(xì)琢，日夜奮戰(zhàn)，終于又迎來了Arco Vue Pro 正式發(fā)布上線！
ArcoDesign 是由字節(jié)跳動 GIP UED 團(tuán)隊和架構(gòu)前端團(tuán)隊聯(lián)合推出的企業(yè)級設(shè)計系統(tǒng)，在打磨了近 3 年之后，通過字節(jié)內(nèi)部大量業(yè)務(wù)沉淀和驗證，開源了 ArcoDesign 設(shè)計系統(tǒng)，旨在讓社區(qū)聽見更多的聲音，為更多中小型企業(yè)及個人設(shè)計師和開發(fā)者提效，創(chuàng)造更多高效美觀的“最佳實(shí)踐”。
Naive Admin Arco 是一個基于 Vue3.0、Vite、 Arco Vue、TypeScript 中后臺解決方案。
Naive Admin Arco 企業(yè)級中后臺前端框架，使用最新的前端技術(shù)棧，并提煉了典型的業(yè)務(wù)模型，頁面，包括二次封裝組件、動態(tài)菜單、權(quán)限校驗、粒子化權(quán)限控制等功能，它可以幫助你快速搭建企業(yè)級中后臺項目
響應(yīng)式、多主題，多配置，快速集成，開箱即用
最新技術(shù)棧，使用 Vue 3、Typescript、Pinia、Vite 等前端前沿技術(shù)
強(qiáng)大的鑒權(quán)系統(tǒng)，對路由、菜單、功能點(diǎn)等支持 3 種鑒權(quán)模式，滿足不同的業(yè)務(wù)鑒權(quán)需求
持續(xù)更新，實(shí)用性頁面模板功能和交互，隨意搭配組合，讓構(gòu)建頁面變得簡單化
更多頁面、功能，組件，請直接在線預(yù)覽查看
AdminPro
Naive Admin NaiveUi 生態(tài)最優(yōu)秀的中后臺框架，全面的系統(tǒng)配置，優(yōu)質(zhì)模板，常用組件，真正一站式開箱即用
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
