方法集合
目前只能想到這些了欠雌，對了像棘，還有事件總線這類的就不考慮了稽亏。
props + emit
最基礎(chǔ)的方式，適用于 父組件和子組件之間的直接傳值缕题，多用于基礎(chǔ)控件截歉，比如input、el-input烟零、el-select這類瘪松。
比較基礎(chǔ)不多介紹了。
Vuex
老牌的狀態(tài)管理方式瓶摆，各種組件之間各種傳值凉逛，好吧專業(yè)術(shù)語叫做狀態(tài)管理性宏。
使用方法呢群井，其實就是一層窗戶紙，捅破了大家就都知道了毫胜，這里不介紹了书斜，可以看我的文集：
http://www.reibang.com/nb/49384194
indexedDB
這個不是前端存儲嗎？也可以共享數(shù)據(jù)酵使？
當(dāng)然可以了荐吉，只是沒有響應(yīng)性而已。
使用方式可以參考這里：http://www.reibang.com/p/607c01749168
當(dāng)然也可以用其他第三方的封裝類來管理口渔。
Vuex挺強(qiáng)大的样屠，只是有個小問題，不支持狀態(tài)的保存，比如一刷新狀態(tài)就沒了注盈，更不用提關(guān)掉網(wǎng)頁等操作了分尸。
那么如果我想長期保存狀態(tài)呢向瓷？這時候就需要用到前端存儲，比如localStrage或者indexedDB栗柒。
Vuex + 前端存儲，二者配合起來就更強(qiáng)大了知举。
indexedDB的特點(diǎn)是可以長期保存數(shù)據(jù)瞬沦，而且容量很大，那么是不是可以把字典數(shù)據(jù)存進(jìn)來呢雇锡？然后讓state來加載這些數(shù)據(jù)逛钻，這樣的話就不用每次（打開頁面）都到后端去獲取數(shù)據(jù)。
既快捷又減輕后端的壓力遮糖。
provide 和 inject 的注入方法
這個還是很簡單粗暴的绣的，目前正在研究，應(yīng)該可以實現(xiàn)代替 Vuex 的數(shù)據(jù)狀態(tài)管理方案欲账。
因為Vuex不太適合Vue3的環(huán)境屡江，應(yīng)該可以有替代方案了。
在這里探討了一下：http://www.reibang.com/p/25b8e8a7e319
當(dāng)然還很粗糙赛不，距離完善還有很長的路要走惩嘉。
后端API
這個家伙怎么也來了？跑錯片場了吧踢故。
其實不然文黎，可能大家早就在默默的使用這種方式了。
比如博客網(wǎng)站殿较，打開一篇博文耸峭，看著興起寫了一個討論發(fā)了出去。
這時候討論組件會把討論數(shù)據(jù)提交給后端淋纲，后端處理后返回給前端劳闹，討論組件得到確認(rèn)回復(fù)后，是不是要告訴討論列表組件：你有新的消息洽瞬，請注意更新一下本涕。
這是討論組件就會向后端API申請新的討論列表數(shù)據(jù)。
這樣看來伙窃，討論數(shù)據(jù)是不是經(jīng)由后端API傳遞給另一個組件的呢菩颖？
好吧，有點(diǎn)杠的味道为障，但是原理就是這樣的晦闰，我是想告訴大家放祟，不要限制思維，發(fā)散一下總不會有錯呻右。
可能有人會說舞竿，你這是古老的思路，完全不懂現(xiàn)在的前端開發(fā)的思想窿冯，還骗奖。。醒串。执桌。
好吧，還是上面的例子芜赌，稍微改一下流程仰挣。
討論組件向后端API提交數(shù)據(jù)的同時，把討論數(shù)據(jù)共享給列表組件缠沈，列表組件不管三七二十膘壶，先顯示了再說。
這樣用戶可以在第一時間在討論列表里面看到自己發(fā)的討論信息洲愤。
但是這還沒有完颓芭，后端有沒有成功保存討論呢？
討論組件得到后端的回復(fù)之后柬赐，還要做一下處理：
1亡问、如果成功了，告知討論組件新的討論數(shù)據(jù)的ID
2肛宋、如果失敗了州藕，告知討論組件，剛才的那條討論數(shù)據(jù)沒成功酝陈，你得通知用戶床玻。
討論組件也要做相應(yīng)的處理。
1沉帮、如果得到成功的通知锈死，設(shè)置新的ID，為刪除操作提供ID遇西，否則刪除操作咋辦馅精。
2严嗜、如果得到失敗的通知粱檀，要告知用戶失敗了，并且問問用戶漫玄，是否重發(fā)茄蚯。
然后還有個小問題压彭，如果討論非常激烈，又有幾個新的討論出現(xiàn)了渗常，那么什么時候更新這些討論壮不？是讓用戶手動更新，還是自動更新皱碘，還是討論組件提交數(shù)據(jù)后询一，后端自動判斷是否有新的討論，如果有癌椿，一起返回給前端健蕊？
好像跑題了。
總之要設(shè)計好一個應(yīng)用踢俄，各種細(xì)節(jié)問題缩功，用戶交互問題，都是需要考慮的都办。果然跑題了嫡锌。。琳钉。
