❶ web前端開之網站搭建框架之vue詳解
網站搭建框架之vue
Vue是web前端快速搭建網站的框架之一。它與jQuery有所不同，是以數據驅動web界面（以操作數據改變頁面，而jQuery是以操作節點來改變頁面），同時，vue還實現了數據的雙向綁定，可及時響應用戶的輸入。最主要的是vue的寫法簡單，容易掌握，組件形式可以大大提高工作效率。
對於vue的使用可以分為兩種使用形式：1.引入vue.js文件，在js中將vue實例化；2.通過node安裝第三方包--vue，搭建腳手架，用腳手架將頁面分成幾個組件編寫，從而利用組件來搭建頁面。
引入vue.js的寫法
Vue分為V層（視圖層）和M層（數據層），一般都是由M層的數據來驅動V層的改變。而vue的常用指令數量不多且寫法簡單。常用的有v-html、v-text、v-show、v-if、v-else、v-for、v-bind:、v-model。v-html和v-text都是將數據寫進標簽內，但它們的不同之處在於v-text會將標簽當做文本內容寫入
，而v-html則會對標簽進行編譯，只顯示標簽內的內容。
至於v-show、v-if、v-else這三個指令都是通過布爾值的判斷來執行的，當布爾值為真時，設置了v-show、v-if指令的標簽會顯示出來，當布爾值為假時，標簽隱藏；而v-else與這兩個指令相反。除此之外，v-show和v-if、v-else之間也有差別，v-show是改變標簽的display屬性來使標簽顯示或隱藏；而v-if、v-else是通過添加或刪除節點，來顯示或隱藏標簽的。
V-for是vue的一種遍歷方法，這個方法極大的簡化了數組或對象的遍歷並顯示到頁面的步驟
而v-bind：是對html屬性或自定義屬性的數據驅動方式，格式為v-bind:href，可簡寫為：href。對於類（class）的操作是通過布爾值來判斷增加或者隱藏類，同時。類和樣式（style）所接受的數據類型為對象。
V-model指令的作用是將數據進行雙向綁定，僅限於輸入類型標簽。當用戶在頁面輸入時，數據層的數據會跟著改變。這是VM模式。由v驅動m。
除了這些普通的指令之外，還有事件指令v-on:，可簡寫為@+事件名，例如：@click，並將執行函數寫到vue的methods中
通過腳手架來寫項目的話，可用通過寫組件，再將組件引入（注冊）到另一個vue文件里拼接在一起，從而構建出一個頁面。
（組件書寫格式）
（組件整合）
（注冊路由）
路由是通過vue-router來實現的，在注冊路由的時候要將router實例化。不同的路由跳轉不同的頁面，這是搭建單頁面應用的優勢。
而父組件與子組件之間的通訊可以通過props將父組件的信息傳遞給子組件，改變子組件的內容，這樣子組件的復用就不會有障礙了，而子組件傳遞信息給父組件或者其他組件的通訊則需vuex。
通過引入vuex並實例化一個Vuex.Store作為一個公共平台，將數據進行傳輸。通過vue的computed方法接收數據，通過methods方法改變數據。而這個公用平台可以實現組件與組件之間的信息傳遞，從而實現組件之間的交互。
通過一個星期的實戰，深深的體會到了vue的優勢，在構建移動端這方面的效率很高。但在搭建的過程中，還是少不了與jQuery結合，畢竟每個工具都有其優點，擇其優而用是明智的選擇。
❷ 2021-11-10.Vue前端面試題及答案
const vm = new Vue({
...
methods: {
handlerEvent(event) {
console.log(event) // 滑鼠點擊時，獲取到事件對象
}
}
})
1、如果只是事件函數的調用，函數名稱後面不要添加括弧
好處：函數執行時，第一個形式參數會被系統自動注入
一個事件對象，提供給函數使用
@click="handlerEvent"
2、如果事件函數調用執行時，需要傳遞參數，函數名稱後面
必須添加括弧，如果要使用事件對象，就必須手工注入(固定語法)
@click="handlerEvent($event)"
事件冒泡是JS語法中的一種事件觸發機制，描述的是目標元素上的事件一旦發生，就會根據DOM節點結構，將事件逐步依次觸發到父節點上的一種事件機制
原生JS中通過兼容性語法阻止事件冒泡
event.stopPropagation?event.stopPropagation():event.cancelBubble=true
Vue中對於事件冒泡的處理進行了封裝，提供了事件修飾符完成阻止冒泡行為
固定語法：標簽對象的事件屬性上，添加 @事件對象.stop="處理函數"
.self事件修飾符的作用，就是讓事件的觸發方式只能由當前標簽上發生的事件觸發！
.lazy作為表單修飾符，經常用在表單元素上，用於將表單數據的同步機制延遲到表單元素失去焦點時再進行同步，節省資源、提高整體效率！
Vue數據雙向綁定的特性，指代的是Vue實例中的數據和網頁視圖中的數據綁定，實例中數據的更新會直接影響視圖的渲染展示，視圖中的數據更新會自動同步到實例中的數據，這樣的操作機制就是數據雙向綁定機制；Vue底層主要是通過Object.defineProperty()數據劫持的操作方式完成的！
數據劫持本質上就是一種變數的高級聲明方式，通過數據劫持的語法聲明的變數，我們可以針對變數數據的查詢、編輯進行監聽，隨時根據變數的使用情況進行功能的添加，如數據的雙向綁定，完成數據的自動同步和自動渲染！
❸ VUE在前端裡面主要是做什麼的呢
Vue是一個js框架。什麼叫框架？個人理解是對原生JS ，html,css的功能進行封裝之後形成的一個語言。
比如，你需要蓋一座房子，你用原生js，html，css寫代碼相當於你用手一塊磚一塊磚地壘。而使用Vue，Vue已經給你了一面牆，一根房梁，一扇門，你需要做的是把門牆梁拼成房子。它幫助你提高開發效率。你只需要按照它的規矩來寫三段部分：<template>、<script>、<style>就能完成平時html、css、js的功能。頁面視圖展示，前後數據交互都完成了。
之後使用webpack等工具，會將vue語法轉換為html,js,css。
其實使用Vue開發和原生html,css,js開發步驟邏輯是一樣的。
除此之外，vue還有動態綁定，數據驅動等等特點，這些都是題外話。我相信我的回答已經解決了你的問題，如果感覺有幫助，請採納我的答案。
❹ php文件如何接受vue前端axios傳過來的參數實現登錄驗證
前端請求要麼GET要麼POST。
你在php裡面獲取的話可以使用超全局變數： $_GET/$_POST。
根據對應的請求方式可以直接獲取到所有的請求數據。
❺ Vue在前端開發中需要注意什麼
基於Vue官方風格指南整理
一、強制
1. 組件名為多個單詞
組件名應該始終是多個單詞的，根組件 App 除外。
正例：
export default {
name: 'TodoItem',
// ...
}
反例：
export default {
name: 'Todo',
// ...
}
2. 組件數據
組件的 data 必須是一個函數。
當在組件中使用 data 屬性的時候 (除了 new Vue 外的任何地方)，它的值必須是返回一個對象的函數。
正例：
// In a .vue file
export default {
data () {
return {
foo: 'bar'
}
}
}
// 在一個 Vue 的根實例上直接使用對象是可以的，
// 因為只存在一個這樣的實例。
new Vue({
data: {
foo: 'bar'
}
})
反例：
export default {
data: {
foo: 'bar'
}
}
3. Prop定義
Prop 定義應該盡量詳細。
在你提交的代碼中，prop 的定義應該盡量詳細，至少需要指定其類型。
正例：
props: {
status: String
}
// 更好的做法！
props: {
status: {
type: String,
required: true,
validator: function (value) {
return [
'syncing',
'synced',
'version-conflict',
'error'
].indexOf(value) !== -1
}
}
}
反例：
// 這樣做只有開發原型系統時可以接受
props: ['status']
4. 為v-for設置鍵值
總是用 key 配合 v-for。
在組件上_總是_必須用 key 配合 v-for，以便維護內部組件及其子樹的狀態。甚至在元素上維護可預測的行為，比如動畫中的對象固化 (object constancy)，也是一種好的做法。
正例：
<ul>
<li
v-for="todo in todos"
:key="todo.id"
>
{{ todo.text }}
</li>
</ul>
反例：
<ul>
<li v-for="todo in todos">
{{ todo.text }}
</li>
</ul>
5.避免 v-if 和 v-for 用在一起
永遠不要把 v-if 和 v-for 同時用在同一個元素上。
一般我們在兩種常見的情況下會傾向於這樣做：
為了過濾一個列表中的項目 (比如 v-for="user in users" v-if="user.isActive")。在這種情形下，請將 users 替換為一個計算屬性 (比如 activeUsers)，讓其返回過濾後的列表。
為了避免渲染本應該被隱藏的列表 (比如 v-for="user in users" v-if="shouldShowUsers")。這種情形下，請將 v-if 移動至容器元素上 (比如 ul, ol)。
正例：
<ul v-if="shouldShowUsers">
<li
v-for="user in users"
:key="user.id"
>
{{ user.name }}
</li>
</ul>
反例：
<ul>
<li
v-for="user in users"
v-if="shouldShowUsers"
:key="user.id"
>
{{ user.name }}
</li>
</ul>
6. 為組件樣式設置作用域
對於應用來說，頂級 App 組件和布局組件中的樣式可以是全局的，但是其它所有組件都應該是有作用域的。
這條規則只和單文件組件有關。你不一定要使用 scoped 特性。設置作用域也可以通過 CSS Moles，那是一個基於 class 的類似 BEM 的策略，當然你也可以使用其它的庫或約定。
不管怎樣，對於組件庫，我們應該更傾向於選用基於 class 的策略而不是 scoped 特性。
這讓覆寫內部樣式更容易：使用了常人可理解的 class 名稱且沒有太高的選擇器優先順序，而且不太會導致沖突。
正例：
<template>
<button class="c-Button c-Button--close">X</button>
</template>
<!-- 使用 BEM 約定 -->
<style>
.c-Button {
border: none;
border-radius: 2px;
}
.c-Button--close {
background-color: red;
}
</style>
反例：
<template>
<button class="btn btn-close">X</button>
</template>
<style>
.btn-close {
background-color: red;
}
</style>
<template>
<button class="button button-close">X</button>
</template>
<!-- 使用 `scoped` 特性 -->
<style scoped>
.button {
border: none;
border-radius: 2px;
}
.button-close {
background-color: red;
}
</style>
二、強烈推薦（增強可讀性）
1. 組件文件
只要有能夠拼接文件的構建系統，就把每個組件單獨分成文件。
當你需要編輯一個組件或查閱一個組件的用法時，可以更快速的找到它。
正例：
components/
|- TodoList.vue
|- TodoItem.vue
反例：
V
ue.component('TodoList', {
// ...
})
Vue.component('TodoItem', {
// ...
})
2. 單文件組件文件的大小寫
單文件組件的文件名應該要麼始終是單詞大寫開頭 (PascalCase)
正例：
components/
|- MyComponent.vue
反例：
components/
|- myComponent.vue
|- mycomponent.vue
3. 基礎組件名
應用特定樣式和約定的基礎組件 (也就是展示類的、無邏輯的或無狀態的組件) 應該全部以一個特定的前綴開頭，比如 Base、App 或 V。
正例：
components/
|- BaseButton.vue
|- BaseTable.vue
|- BaseIcon.vue
反例：
components/
|- MyButton.vue
|- VueTable.vue
|- Icon.vue
4. 單例組件名
只應該擁有單個活躍實例的組件應該以 The 前綴命名，以示其唯一性。
這不意味著組件只可用於一個單頁面，而是每個頁面只使用一次。這些組件永遠不接受任何 prop，因為它們是為你的應用定製的，而不是它們在你的應用中的上下文。如果你發現有必要添加 prop，那就表明這實際上是一個可復用的組件，只是目前在每個頁面里只使用一次。
正例：
components/
|- TheHeading.vue
|- TheSidebar.vue
反例：
components/
|- Heading.vue
|- MySidebar.vue
5. 緊密耦合的組件名
和父組件緊密耦合的子組件應該以父組件名作為前綴命名。
如果一個組件只在某個父組件的場景下有意義，這層關系應該體現在其名字上。因為編輯器通常會按字母順序組織文件，所以這樣做可以把相關聯的文件排在一起。
正例：
components/
|- TodoList.vue
|- TodoListItem.vue
|- TodoListItemButton.vue
components/
|- SearchSidebar.vue
|- SearchSidebarNavigation.vue
反例：
components/
|- SearchSidebar.vue
|- NavigationForSearchSidebar.vue
6. 組件名中的單詞順序
組件名應該以高級別的 (通常是一般化描述的) 單詞開頭，以描述性的修飾詞結尾。
正例：
components/
|- SearchButtonClear.vue
|- SearchButtonRun.vue
|- SearchInputQuery.vue
|- SearchInputExcludeGlob.vue
|- SettingsCheckboxTerms.vue
|- .vue
反例：
components/
|- ClearSearchButton.vue
|- ExcludeFromSearchInput.vue
|- LaunchOnStartupCheckbox.vue
|- RunSearchButton.vue
|- SearchInput.vue
|- TermsCheckbox.vue
7. 模板中的組件名大小寫
總是 PascalCase 的
正例：
<!-- 在單文件組件和字元串模板中 -->
<MyComponent/>
反例：
<!-- 在單文件組件和字元串模板中 -->
<mycomponent/>
<!-- 在單文件組件和字元串模板中 -->
<myComponent/>
8. 完整單詞的組件名
組件名應該傾向於完整單詞而不是縮寫。
正例：
components/
|- StudentDashboardSettings.vue
|- UserProfileOptions.vue
反例：
components/
|- SdSettings.vue
|- UProfOpts.vue
9. 多個特性的元素
多個特性的元素應該分多行撰寫，每個特性一行。
正例：
<img
src="htorg/images/logo.png"
alt="Vue Logo"
>
<MyComponent
foo="a"
bar="b"
baz="c"
/>
反例：
<img src="h/logo.png" alt="Vue Logo">
<MyComponent foo="a" bar="b" baz="c"/>
10. 模板中簡單的表達式
組件模板應該只包含簡單的表達式，復雜的表達式則應該重構為計算屬性或方法。
復雜表達式會讓你的模板變得不那麼聲明式。我們應該盡量描述應該出現的是什麼，而非如何計算那個值。而且計算屬性和方法使得代碼可以重用。
❻ vue 前端如何判斷某個值不為0
非同步載入完成後 調用ui線程的handle來sendMessage 在handle的dispatchMessage中處理消息，做progressBar的隱藏處理
❼ vue+django使用session的用戶驗證怎麼做
和朋友合作一個小項目，我負責前端，他負責後台，目前對用戶登陸驗證這塊不太明白應該怎麼做。了解了下有傳統session的方式和access token的方式。
access token的方式我大概明白前端的工作具體怎麼做，用戶名密碼驗證通過後後台返回一個token，以後前端路由加http攔截所有的請求頭都要附上這個token。但是後台的操作會比較麻煩。
❽ 如何用 Vue 實現前端
前端許可權控制並不是新生事物，早在後端 MVC 時代，web 系統中就已經普遍存在對按鈕和菜單的顯示 / 隱藏控制，只不過當時它們是由後端程序員在 jsp 或者 php 模板中實現的。
隨著前後端分離架構的流行，前後端以介面為界實現開發解耦，許可權控制也一分為二，前端許可權控制的所有權才真正回到了前端。
可能有的同學會想，前後端分別做一套控制，是不是將事情復雜化了，而且從根本上講前端沒有秘密，後端才是許可權的關鍵，那是不是只在後端做控制就可以了。
❾ VUE 前端獲取驗證碼的四種格式
如果需要獲取驗證碼，同時也需要獲取head信息，這樣時會發送兩次請求，就會有錯，需要使用其他方法；如果不需要獲取head信息，可以使用
❿ Vue項目前後端分離下的前端鑒權方案
# Vue項目前後端分離下的前端鑒權方案
### 技術棧
前端Vue全家桶，後台.net。
### 需求分析
1. 前端路由鑒權，屏蔽地址欄入侵
2. 路由數據由後台管理，前端只按固定規則非同步載入路由
3. 許可權控制精確到每一個按鈕
4. 自動更新token
5. 同一個瀏覽器只能登錄一個賬號
### 前端方案
> 對於需求1、2、3，採用非同步載入路由方案
1. 首先編寫vue全局路由守衛
2. 排除登錄路由和無需鑒權路由
3. 登錄後請求拉取用戶菜單數據
4. 在vuex里處理菜單和路由匹配數據
5. 將在vuex里處理好的路由數據通過`addRoutes`非同步推入路由
```
router.beforeEach((to, from, next) => {
// 判斷當前用戶是否已拉取許可權菜單
if (store.state.sidebar.userRouter.length === 0) {
// 無菜單時拉取
getMenuRouter()
.then(res => {
let _menu = res.data.Data.ColumnDataList || [];
// if (res.data.Data.ColumnDataList.length > 0) {
// 整理菜單&路由數據
store.commit("setMenuRouter", _menu);
// 推入許可權路由列表
router.addRoutes(store.state.sidebar.userRouter);
next({...to, replace: true });
// }
})
.catch(err => {
// console.log(err);
// Message.error("伺服器連接失敗");
});
} else {
//當有用戶許可權的時候，說明所有可訪問路由已生成 如訪問沒許可權的菜單會自動進入404頁面
if (to.path == "/login") {
next({
name: "index"
});
} else {
next();
}
}
} else {
// 無登錄狀態時重定向至登錄 或可進入無需登錄狀態路徑
if (to.path == "/login" || to.meta.auth === 0) {
next();
} else {
next({
path: "/login"
});
}
}
});
```
##### 注意
> 我這里無需鑒權的路由直接寫在router文件夾下的index.js，通過路由元信息meta攜帶指定標識
```
{
path: "/err-404",
name: "err404",
meta: {
authentication: false
},
component: resolve => require(["../views/error/404.vue"], resolve)
},
```
> 上面說到路由是根據後台返回菜單數據根據一定規則生成，因此一些不是菜單，又需要登錄狀態的路由，我寫在router文件夾下的router.js里，在上面步驟4里處理後台返回菜單數據時，和處理好的菜單路由數據合並一同通過`addRoutes`推入。
這樣做會有一定的被地址欄入侵的風險,但是筆者這里大多是不太重要的路由，如果你要求咳咳，可以定一份字典來和後台介面配合精確載入每一個路由。
```
// 加入企業
{
path: "/join-company",
name: "join-company",
component: resolve => require([`@/views/index/join-company.vue`], resolve)
},
```
> 在vuex中將分配的菜單數據轉化為前端可用的路由數據，我是這樣做的：
管理系統在新增菜單時需要填寫一個頁面地址欄位`Url`,前端得到後台菜單數據後根據`Url`欄位來匹配路由載入的文件路徑，每個菜單一個文件夾的好處是：你可以在這里拆分js、css和此菜單私有組件等
```
menu.forEach(item => {
let routerItem = {
path: item.Url,
name: item.Id,
meta: {
auth: item.Children,
}, // 路由元信息 定義路由時即可攜帶的參數，可用來管理每個路由的按鈕操作許可權
component: resolve =>
require([`@/views${item.Url}/index.vue`], resolve) // 路由映射真實視圖路徑
};
routerBox.push(routerItem);
});
```
> 關於如何精確控制每一個按鈕我是這樣做的，將按鈕編碼放在路由元信息里，在當前路由下匹配來控制頁面上的按鈕是否創建。
菜單數據返回的都是多級結構，每個菜單下的子集就是當前菜單下的按鈕許可權碼數組，我把每個菜單下的按鈕放在此菜單的路由元信息`meta.auth`中。這樣作的好處是：按鈕許可權校驗只需匹配每個菜單路由元信息下的數據，這樣校驗池長度通常不會超過5個。
```
created() {
this.owner = this.$route.meta.auth.map(item => item.Code);
}
methods: {
matchingOwner(auth) {
return this.owner.some(item => item === auth);
}
}
```
> 需求4自動更新token，就是簡單的時間判斷，並在請求頭添加欄位來通知後台更新token並在頭部返回，前端接受到帶token的請求就直接更新token
```
// 在axios的請求攔截器中
let token = getSession(auth_code);
if (token) config.headers.auth = token;
if (tokenIsExpire(token)) {
// 判斷是否需要刷新jwt
config.headers.refreshtoken = true;
}
// 在axios的響應攔截器中
if (res.headers.auth) {
setSession(auth_code, res.headers.auth);
}
```
> 對於需求5的處理比較麻煩，要跨tab頁只能通過`cookie`或`local`,筆者這里不允許使用`cookie`因此採用的`localstorage`。通過打開的新頁面讀取`localstorage`內的`token`數據來同步多個頁面的賬號信息。`token`使用的`jwt`並前端md5加密。
這里需要注意一點是頁面切換要立即同步賬號信息。
> 經過需求5改造後的全局路由守衛是這樣的：
```
function _AUTH_() {
// 切換窗口時校驗賬號是否發生變化
window.addEventListener("visibilitychange", function() {
let Local_auth = getLocal(auth_code, true);
let Session_auth = getSession(auth_code);
if (document.hidden == false && Local_auth && Local_auth != Session_auth) {
setSession(auth_code, Local_auth, true);
router.go(0)
}
})
router.beforeEach((to, from, next) => {
// 判斷當前用戶是否已拉取許可權菜單
if (store.state.sidebar.userRouter.length === 0) {
// 無菜單時拉取
getMenuRouter()
.then(res => {
let _menu = res.data.Data.ColumnDataList || [];
// if (res.data.Data.ColumnDataList.length > 0) {
// 整理菜單&路由數據
store.commit("setMenuRouter", _menu);
// 推入許可權路由列表
router.addRoutes(store.state.sidebar.userRouter);
next({...to, replace: true });
// }
})
.catch(err => {
// console.log(err);
// Message.error("伺服器連接失敗");
});
} else {
//當有用戶許可權的時候，說明所有可訪問路由已生成 如訪問沒許可權的菜單會自動進入404頁面
if (to.path == "/login") {
next({
name: "index"
});
} else {
next();
}
}
} else {
// 無登錄狀態時重定向至登錄 或可進入無需登錄狀態路徑
if (to.path == "/login" || to.meta.auth === 0) {
next();
} else {
next({
path: "/login"
});
}
}
});
}
```
> 經過需求5改造後的axios的請求攔截器是這樣的，因為ie無法使用`visibilitychange`，並且嘗試網路其他屬性無效，因此在請求發出前做了粗暴處理：
```
if (ie瀏覽器) {
setLocal('_ie', Math.random())
let Local_auth = getLocal(auth_code, true);
let Session_auth = getSession(auth_code);
if (Local_auth && Local_auth != Session_auth) {
setSession(auth_code, Local_auth, true);
router.go(0)
return false
}
}
```
> 這里有一個小問題需要注意：因為用的`local`因此首次打開瀏覽器可能會有登錄已過期的提示，這里相信大家都能找到適合自己的處理方案
### 結語
經過這些簡單又好用的處理，一個基本滿足需求的前後端分離前端鑒權方案就誕生啦