前言
平常 你在開發(fā)過程中是不是經(jīng)常會遇到這種場景：
一個(gè)頁面共有多個(gè)區(qū)域， 頭部區(qū)域和中間區(qū)域是兄弟組件 頭部區(qū)域有一個(gè) 按鈕 會修改 中間部分的內(nèi)容
正常解決方案
正常我們的解決方案 無非就是 props搭配emit 或者bus 總線：mitt 或者 子組件emit出去父組件用ref獲取組件實(shí)例去改參數(shù)等等面哥，但是我同事不一樣 后面會敘述
props+ emit
父組件
Header 組件
Content 組件
這個(gè)應(yīng)該是平常我們用的比較多的方式對吧
- 1）將 title變量提升到 父組件
- 2）header組件將事件emit 出去 在父組件中修改 title 的值
emit + ref
省略 在header 中 點(diǎn)擊事件中 emit 出去 在父組件利用 ref 獲取 content 組件中的 實(shí)例 然后直接修改 title內(nèi)容
mitt
這里就省略了 無非是借用了 mitt 的emit 事件 和 on 事件 發(fā)布訂閱 進(jìn)行修改數(shù)據(jù)
或者你還有其他的方案 我覺得 應(yīng)該也是大差不差 主要看下面的方式
我同事的方案
重點(diǎn)到了 我看了同事的方案是 provide + inject + ref 實(shí)例的方式
父組件
Header 組件
Content 組件
他的思路是
- 利用provide 在父組件中 獲取所有子組件的實(shí)例
- 利用 inject 將所有的子組件實(shí)例注入到所有的 給自的子組件中
- 這樣 就可以直接 利用注入的provideRefs 獲取到其他ref實(shí)例 就可以直接去修改 對應(yīng)組件中的參數(shù) 或者調(diào)用 內(nèi)部的方法
- 但是得注意 你必須要在子組件defineExpose 拋出你要修改的參數(shù) 或者 方法這樣其他組件才能調(diào)用到
我看了之后 直呼一聲：
總結(jié)
這種思路確實(shí)比較清奇 讶泰，如果在 組件比較多、比較復(fù)雜的時(shí)候 檐涝，跨組件通信 確實(shí)是比較麻煩的遏匆，你得寫很多代碼 各種 emit 各種 props 然后狀態(tài)在父組件中 修改之后 同步到子組件中，舉個(gè)例子：
場景一：
要是 header組件 按鈕得調(diào)用 content的 刷新表格的方法的話 你八成得：
1谁榜、在父組件中 弄一個(gè) fetchTableFlag 變量 傳遞到content 組件中
2幅聘、在header組件中 點(diǎn)擊按鈕的時(shí)候 emit 到父組件 去修改fetchTableFlag 的值
3、在 Content 組件中watch fetchTableFlag 的變化然后調(diào)用 刷新表格的方法
這樣的交互多了話 可能就會導(dǎo)致會有很多變量 導(dǎo)致代碼量增加 利用他的方法的話 某種程度上說確實(shí) 減少了不少代碼
場景二：
如果組件有很多 不僅僅是這三種組件 比如 爺孫組件通信 或者兄弟組件有五六個(gè)的時(shí)候 你可能會考慮使用 pinia 但是 他們其實(shí)并沒有多少的公用參數(shù) 可能只是這個(gè)組件改變了一下另一個(gè)組件的狀態(tài) 給人感覺是不是放到 pinia 里面會比較重窃植，用他的這種方式的話 就 就把傳參扁平化了
但是我個(gè)人覺得這種方式帝蒿，還是不推薦使用，因?yàn)樗蚱屏藇ue 的單項(xiàng)數(shù)據(jù)流的規(guī)巷怜，導(dǎo)致數(shù)據(jù)流轉(zhuǎn)不清晰葛超，可是vue 既然創(chuàng)造了provide 和 ref 實(shí)例進(jìn)行傳參，那么自然有他存在的道理延塑，我們同事之間對這種方式褒貶不一绣张，jym 你們覺得呢？
作者：前端摸魚杭小哥
鏈接：
https://juejin.cn/post/7301968484766728226
