前言：這篇介紹到好友的添加與好友狀態的實時渲染，寫代碼之前，我們先經過縝密的思考再動手，盡管這樣子寫出來的代碼也并不會是最好的一次。但至少只要你大體上摸準了它的脈搏之后的細節修改也只是在大廈下填填補補而不至于推到大廈再重來。那我們仔細觀察上面的數據。再觀察下我們的數據表。

rel_status 字段我們用于對好友之間的關系進行判斷，參照QQ微信等的設計，當我們第一次沒點進去之前有多少條未處理的請求我們就顯示一個數字幾，那么這里其實就隱含了兩個狀態，一個是未處理狀態，一個是已處理狀態。同時假設我們已經點了進去我們不一定會點擊添加好友。但他仍然是已處理狀態（即我們返回之后已經不會再有tips提示）；假如是被請求方被申請了好友，他們添加了好友，那他們就是已是好友狀態。還有一個狀態是你是申請方添加別人為好友。
所以我們得規范下rel_status的定義，方便對他進行數據的匹配與展示。當然你的定義不一定要全隨我，我這里只是提供一種思路。
rel_status: 取值范圍 0 - 4 (0表示雙方已經為好友，1表示當前用戶與朋友是申請方與接受方的關系，2表示當前用戶與朋友是接收方與申請方的關系，3表示未處理的當前用戶與朋友是申請方與接收方的關系，4表示未處理的當前用戶與朋友是接收方與申請方的關系)

代入一個流程，我們看看這樣子定義是否會有問題：我們的首頁渲染的tips應該是 rel_status 為 3 或者4 同時 user_id 是發送方或者接收方的數據條數。當我們點擊進去的時候，將這些數據的rel_status 分別更新為1 或 2。等等，如果這樣子做你考慮到如何將他分別更新 1 或 2了嗎？你將使用兩條更改語句！（將rel_status為3 更新 為rel_status 為 1，將rel_status為4更新為2），到這里的時候我們應該能意識到我們的表的結構并不理想，其中的1234的關鍵變量在于處理和未處理的關系，我們可以通過生成這一個狀態的變量，就可以通過一條語句去判斷他的消息的未讀數。

經過思考，我們決定rel_status定義（*0表示當前用戶與朋友是申請方與接受方的關系，1表示當前用戶與朋友是接收方與申請方的關系，2表示雙方已經為好友。）同時在數據庫里添加新的字段，handle_status（0表示未處理，1表示已處理）用于表示當前的消息是否已經被處理。

我們再代入進流程，首頁渲染時，我們只需要count當前用戶 在自己是被請求的狀態這個handle_status為0 的數目 ，當進入好友請求組件的時候，我們將當前的用戶作為接收方的所有handle_status為0改變為1；

好，至此我們準備的思路已經大體上可以編寫代碼了，上面的主要就是對數據庫的表的結構進行優化，這也是我第一次寫的不夠好的地方，狀態太過耦合，只用一個狀態去表示這個稍微復雜點的好友的各種狀態顯得邏輯太過混亂，總之：通過一個狀態去表達兩種以上的復雜狀態明顯是會造成邏輯混亂的，同時也會造成冗余，為了使我們的代碼更加優雅，我們使用handle_status表示這個請求是否被處理，而這個其實就是是否被看見（進入處理的頁面（或者是進行明顯會造成‘處理’這種結果的操作），我們就可以更新數據庫了）

觀察我們的頁面，我們現在需要做的是在他們渲染的時候同時判斷他們之間的關系，然后實時把他渲染成相應的按鈕。乍一看這不要查詢兩次嗎？他們的關系存儲在friend表，而用戶的信息在user表。僅憑我前面的教程理解了之后自己解決這個實時渲染其實也不太有問題（你能做到的）。這并不算太難。但是我希望能在這里就把連接查詢告訴給你。我們已經學會了如何在一張表中讀取數據，這是相對簡單的，但是在真正的應用中經常需要從多個數據表中讀取數據。

mysql連接查詢
mysql連接查詢有三種，一種是inner join（內連接），一種是左連接，一種是右連接。


右連接我想我就不必放了。但其實這里我們需要理解的是，所謂的內連接就是兩個表的交集（怎么理解？比如我user表的user_id 與friend表的user_id 相連，他們的數據條數肯定是相同的，假如我們查找所有，那兩個表的所有字段由friend表跟user表都會在一張表上返回），而假如是左連接，由于我們有的用戶不一定有請求添加好友等等的操作，此時左連接仍然返回左邊這張user表的所有字段而通過user_id查找不到的則返回空。 現在不太理解也沒關系，隨著代碼跟文字慢慢理解。
mysql 連接 語句
select 字段 from table1 as t1 join table2 as t2 on t1.id = t2.id
當然你仍然可以在這個基礎上添加條件查詢。

首先我們應該處理上個章節我們寫的用戶方法，通過這個連接查詢再去獲取一下rel_status。然后通過這個rel_status 去判斷 實時渲染。這個語句可能會讓你有點吃力，我稍微解釋一下這么寫的原因：使用左連接確保即使右邊無匹配的值，我們也可以將user表的數據返回。假如匹配的數據存在我們應該確保返回的數據當前的用戶ID是作為別人的朋友ID而存在的，意思是：我們查詢的是查詢中的用戶ID與我們當前（作為他的朋友）的ID的關系 實在覺得一時理解困難就先跳過吧，隨著教程的深入，連接查詢的使用增多你會越來越理解。哦對了，注意下join里的寫法，是使用了ES6的模板字符串。分號不要寫錯了。

在前端先處理一下根據好友狀態渲染相應的按鈕塊，這里不要搞混，展示在頁面的用戶如果被我們申請，我們通過接口返回他的狀態應該是0（查詢語句中排除了自己作為friends表的user_id 的數據），詳情參考上面的定義。

添加好友的處理應該有四種邏輯，一種是雙方都不是好友，一種是對方已經請求了你，一種是你請求對方，一種是雙方都是好友。別著急，我們一個一個來。申請中我們就不必對他添加事件了，我們先在加好友這添加事件。名字隨你起。

1.雙方都不是好友 你請求對方

那我們這里的操作就應該是將他們分別添加進表，同時將請求方的handle_status作為1 插入表明是他們之間的狀態請求方已經處理，而被請求方的handle_status應該為0。我們還得明白一個概念：事務控制 ，要么這兩條插入語句全部執行，要么就都不執行。就拿經典的銀行轉賬例子解釋一下為什么加入控制把。
銀行轉賬的實質就是把你的錢扣掉，給別人的錢加錢，假如程序在把你的錢扣掉了的時候出錯了，他下面的給別人加錢的操作執行不了，這么一想你是不是很生氣？一來二算你虧了2倍的錢。所以對于復數級的數據庫操作我們加入事務控制對程序是保險的，程序假如在這一系列的數據庫操作過程中產生了錯誤，它會回滾這個操作，回到你執行這整個流程之前的狀態。

先到后臺寫方法，到dao層加入文件trans.js ，同時router目錄下加入文件trans.js
dao層如下

router 如下

別忘記在主啟動文件中添加依賴

前端方法如下：

其中const {} 使用的是ES6的解構賦值，如果不懂建議去搜索。對之后的代碼編寫很有幫助，其余就不多做解釋了，自己看注釋把。

2.對方已經請求了你

那么此時對方查找到的你的rel_status 應該是0，你作為接受請求方（此時通過接口查找對方的rel_status為1）。當你點擊添加好友時，就證明你同意對方的申請了。這里你也可以根據rel_status對加好友添加條件渲染的控制。我是直接給他合并了。那么回到代碼，我們應該做的只是將兩個用戶的rel_status 更新為2就行，同時為了人性化一點我們也給接受申請方發送一條提示把。

mysql 更新語句
UPDATE table_name SET field1=new-value1, field2=new-value2
跟insert 一樣的，我們也可以不用寫每個字段，使用ali-mysql-client時直接傳入一個json對象就行。這次我們不用更新兩次，因為我們知道user_id跟friend_id是相互的。我們只需要把user_id與friend_id傳進去后端就好。但記得，當他們添加完好友之后，接受申請方得給申請方發條信息。

db.sql('update `friends` set rel_status = 2,handle_status = 1 where (user_id = ? and friend_id = ?) or (friend_id = ? and user_id = ?)').params([userId,friendId,userId,friendId]).execute();

更新處理狀態，好友狀態，使用or運算符表示 這兩種情況都修改，傳入參數，執行sql語句。

router\trans文件如下：

前端代碼如下：

至此搜索頁面的好友的添加就已經完全的實現了。

總結

以上是生活随笔為你收集整理的入门级node+uni-app开发即时通讯聊天室（3）用户的搜索以及好友添加（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。