async/await運用-前端表單彈窗驗證同步書寫方式(React)

在前端項目中，咱們常常會碰到這樣的場景：

　　當前咱們有一個表單須要填寫，在完成表單填寫後通過校驗以後會彈出短信或者其餘形式驗證碼，進行補充校驗，而後一塊兒提交給接口。

場景以下圖：

 

 

當前爲建立操做，編輯操做與重置操做也會複用這個驗證碼彈窗

 

　　一般咱們使用與事件綁定的回調函數進行處理，這也更符合咱們常見的事件響應機制的實現方式。將處理邏輯分散各個回調函數中。

即：formSubmitBtn觸發彈窗展現，而後ModalSubmitBtn觸發api提交邏輯，以後在提交函數中處理返回信息或者將異步的promise實例返回，由上級函數繼續處理。

　　在基於React實現的項目中，爲了更好複用代碼及邏輯，一般會把彈窗、Form這樣的基礎組件結合基礎業務邏輯封裝成組件。在上文描述的流程中，就會出現這樣的問題，咱們的參數、狀態須要在各個組件中頻繁傳遞，每一個組件內部除了自身封裝邏輯外，還會包含當前交互流程的部分業務代碼，當這個驗證碼組件被複用到編輯和重置操做時，就須要藉助傳入不一樣的回調函數來保證各個操做的正常進行，而後還須要根據各個操做不一樣添加後續的判斷。而咱們的處理上下文也會在各個組件內不斷的切換，陷入回調來回傳遞的漩渦。

　　

　　爲了減小回調的干擾，下降業務組件的耦合，咱們能夠藉助promise和async的異步特性，將整個過程從回調嵌套方式轉爲同步方式，集中在一個方法順序執行，減小上下文的切換。

　　好比，將激活彈窗->輸入驗證碼->返回驗證碼看作一個異步動做，建立一個promise實例，而後傳入resolve和reject鉤子函數, 而後在主函數中藉助於async、await去等待響應結果，這樣再同一個context中咱們就能夠順序執行整個流程，減小上下文切換帶來的負擔。

　　

　　進一步思考：若是咱們打算對返回結果進行判斷，若是是驗證碼錯誤(這裏咱們假設返回的status狀態爲403, 正常status爲200)，則保留彈窗，容許用戶繼續填入驗證碼而後提交該怎麼實現呢。

　　答案是借鑑遞歸函數的調用自身的特性實現。

　　對上述行爲，進行抽象，咱們能夠概括爲formSubmit這一行爲在response響應status=403時，產生了循環。對於循環效果，除了咱們常見的for、while等實現形式外，函數調用自身(遞歸)也能夠達到循環的效果。

　　因此，咱們能夠在提交請求後處理response時，在response.status=403條件成立時調用formSubmit函數，達到上述的效果。

　　未完，待續...（後續會補充兩種狀況的模型）