資訊專欄INFORMATION COLUMN
摘要：數據通信首先我們通常說數據傳遞組件通信什么什么的我認為可以分成兩種場景頁面和頁面之間組件和組件之間通信方案不管什么場景在使用的時候一般我們有下面種選擇去實現數據通信選擇通信方案我們在選擇通信方案的時候比如說確定列表頁如何把每一項的傳遞給詳情
數據通信
首先, 我們通常說數據傳遞, 組件通信什么什么的, 我認為可以分成兩種場景:
頁面和頁面之間
組件和組件之間
通信方案不管什么場景, 在使用 Vue 的時候, 一般我們有下面 5 種選擇去實現數據通信.
vuex
storage
props
event
URL queryString
選擇通信方案我們在選擇通信方案的時候, 比如說確定 列表頁如何把每一項的 id 傳遞給 詳情頁的時候,
一般要考慮什么問題? 你是直接全套都是 vuex, 還是說喜歡使用 sessionStorage?
一般我們要考慮下面的幾個問題:
頁面是否可以刷新
頁面是否可以分享 (或者說URL 是否要求 RESTful)
數據更新之后, 所有使用此數據的組件是否都需要響應更新
分析先說 "頁面和頁面之間的通信場景", 首先上面的 5 種方案, 我們可選的有:
vuex, storage, URL queryString.
然后分析一下, 每一種方案, 它對上面的 3個問題, 是不是很好的解決掉了:
備注:
頁面通信場景不會要求實時響應, 因為就算下個頁面的確是實時響應, 你也看不見,
所以主要看 "刷新" 和 "分享"
vuex: 不能刷新, 不能分享
storage: 不能分享
url: 能刷新, 能分享
這樣看來, url queryString 的方式是 "頁面通信場景" 中的最佳選擇, 但是我依舊有疑慮:
我始終覺得把跳轉信息, 暴露給用戶, 是很不好的事情; (心理問題, 可以克服)
url 的長度限制; 這個無所謂的, 2k, 你再怎么傳遞, 我都不會覺得你會出現超過 2k 的情況
url 需要拼接, 這個拼接是否麻煩? 也不麻煩, 只是對象轉字符串.
這樣每個頁面都需要在進入的時候先解析一下 queryString, 這樣是不是增加了麻煩的程度
也可以通過 mixins 來操作. 聚合到 mixins, 況且也不一定很多.
所以我們可以選擇 "url queryString" 作為 "頁面和頁面通信場景" 中的通信方案.
以后你就可以這樣用了:
比如列表頁面跳轉到詳情頁要帶一個 id
this.$router.push({
path: "detail",
query: {
id
}
})
你的 url 會始終長這樣:
https://abc.com/#/?id=123
備注: 如果你的頁面不能刷新和分享, 你完全可以三種方案隨便選, 愛誰誰.
重點: url queryString 的方式, 有一個問題解決不了:
從詳情頁到訂單頁, 通過 queryString 帶了商品信息過來, 假設此時 url 長這樣:
order/?goods=xxx
訂單頁面有一個收貨地址欄, 點擊可以進入地址編輯頁面, 此時的 url 不會帶參數的(你可以試試帶一下看多麻煩)
address-edit/
地址編輯頁面有一個保存按鈕, 點擊會返回到訂單頁面
order/
so, url queryString 丟了.
我目前的解決方案:
針對這種存在多入口的頁面, 一定要在進入它的第一時間, 先把 queryString 存起來.
并且做如下判斷:
if (// 存在 queryString) {
// use queryString
} else {
// use storage
}
但是這種方式還是搞不定 從地址編輯頁返回到訂單頁, 用戶此時分享訂單頁, 分享出去的玩意肯定會是錯的.
現在來說下 "組件和組件之間的通信場景"
上面的 5 種方案, 可以選擇 vuex, event, props, storage
先看下 刷新, 分享和實時響應
vuex, 不能刷新
event, props 能刷新能分享
storage 不能分享 & 實時.
解釋:
為什么 vuex 在這里還是不能刷新
因為如果使用的 state 里面的值是其他頁面設置的而不是 init 就存在的, 刷新丟值.
為什么 event, props 可以做到防刷新防分享
因為這兩個玩意是程序運行它就生效的, 它也可以做到實時更新.
storage 雖然在存的時候有一個事件, 但是這太 trick 了.
所以我們選擇的是 event, props?
分析一下吧.
組件通信可以分成兩種, 父子, 同輩.
父子之間呢:
父傳子: props
子傳父: $emit(event)
這就是 "props down, events up";
但是其實還有:
父傳子: this.$refs.xxx
子傳父: this.$parent.xxx
還有: 自定義 v-model
還有: 讓 props 是一個對象.
同輩之間: event-bus.
所以這就完了? 啥都沒有了? 嗯, 就這樣.
思考
關于 vuex 的應用場景的考慮
不是應該所有的組件, 路由之間的數據傳遞都應該通過 vuex, 當同時存在兩種方式可以選擇的時候,選擇 vuex 的唯一理由只有一個:
需要響應式的狀態
why?
因為 vuex 雖然有輔助函數, 但是用起來還是要 引入, 定義. 而且真的是一刷新頁面就掛了.
可以通過監聽 beforeunload 事件, 在其中緩存 state, 然后在 onload 事件再恢復, 這樣可以避免掉vuex 的丟值.
沒有必要追求全項目統一的一種通信方式, 理論上你不考慮刷新分享, 全項目都用 vuex, 什么事情也不會有的.
vuex 是狀態管理, 不是保存常量的地方.
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/87119.html
摘要：一父組件通過的方式向子組件傳遞數據，而通過子組件可以向父組件通信。而且只讀，不可被修改，所有修改都會失效并警告。 之前寫了一篇關于vue面試總結的文章, 有不少網友提出組件之間通信方式還有很多, 這篇文章便是專門總結組件之間通信的 vue是數據驅動視圖更新的框架, 所以對于vue來說組件間的數據通信非常重要，那么組件之間如何進行數據通信的呢？首先我們需要知道在vue中組件之間存在什么樣...
摘要：本身提供哪幾種通信方式首先靈感源于，支持雙向綁定，本質還是單向數據流。跟一樣，組件間最基本的數據流是通過向子組件傳遞數據。但是在卻很少使用，因為組件可以自定義事件，即后面的組件間通信方式其實就是訂閱發布模式。 例子是在 jsrun.net 平臺編寫，不支持移動端平臺，所以本文建議在 PC 端進行閱讀。 Vue 是數據驅動的視圖框架，那么組件間的數據通信是必然的事情，那么組件間如何進行數...
摘要：本文總結了組件間通信的幾種方式，如和，以通俗易懂的實例講述這其中的差別及使用場景，希望對小伙伴有些許幫助。狀態改變提交操作方法。 前言 組件是 vue.js最強大的功能之一，而組件實例的作用域是相互獨立的，這就意味著不同組件之間的數據無法相互引用。一般來說，組件可以有以下幾種關系：showImg(https://segmentfault.com/img/remote/146000001...
摘要：組件之間的通信是我們在項目中常常碰到的，而選擇合適的通信方式尤為重要，這里總結下作者在實際項目中所運用到的通信方案，如有遺漏，請大家見諒。示例效果如下兄弟組件同級別組件相互間的通信，我們可以使用或著。 Vue組件之間的通信是我們在項目中常常碰到的，而選擇合適的通信方式尤為重要，這里總結下作者在實際項目中所運用到的通信方案，如有遺漏，請大家見諒。文章代碼具體見DEMO；文章首發于imon...
摘要：我在中寫了這段代碼在組件被創建時候將會執行此函數相當于進入頁面的自執行使用方法監聽屬性并執行一個回調函數按道理在元素被創建的時候，會將監聽到的值賦給并且打印。 天地不仁以萬物為芻狗，宇宙無義視眾生如螻蟻 ——蕭鼎和我 上一節列出了５個關鍵點，第一個路由已經解決了，接下來解決第二個問題： 組件的通信問題 一、組件的關系 組件之間的關系無非就是兩種父子關系...
摘要：是一個事件，它向下傳播到當前實例的所有后代。由于后代擴展為多個子樹，事件傳播將會遵循許多不同的路徑。組件修改實現遞歸地在父鏈上傳播事件。 組件通信 父子組件通信 父傳子 props屬性 子傳父 $emit事件 這兩種官方文檔里有很詳細的介紹就不解釋了 還是舉個栗子： //parent.vue父組件 parent: {{money}} ...
閱讀 2176·2023-04-25 15:00
閱讀 2350·2021-11-18 13:14
閱讀 1170·2021-11-15 11:37
閱讀 3092·2021-09-24 13:55
閱讀 1230·2019-08-30 15:52
閱讀 2650·2019-08-29 12:35
閱讀 3365·2019-08-29 11:04
閱讀 1212·2019-08-26 12:13
