眾所周知，在客戶端中，表單是乙個相當重要的內容。隨著技術的發展，在提交表單資料的時候，某些表單驗證環節會放在前端進行。因此，我們無可避免的要寫一堆 if 來處理，同時大多數的時候，如果需要提醒某些錯誤資訊時，需要加入 else 以及 else if 來控制，當然也可以使用 retrun。不過隨著表單越來越複雜，表單項之間的關聯越來越複雜的時候，看著一屏都放不下的判斷巢狀，心中是萬千草泥馬奔騰而過。
promise 的出現主要是為了解決複雜的**巢狀，因此在這裡也是借用了這個特點，解決我們的痛點。**見下：
function validate (scb = () => {}, ecb= () => {}) ).then((result) => ).catch((err) => );
}
**中 area 1 是主要的邏輯判斷區， area 2 執行時表示 area 1 中的驗證全通過， area 3 則是全通過之後的成功**函式(scb => successcallback 縮寫， ecb 同)，相反 area 4 是未通過之後的處理區域。這段主要是利用 reject 阻斷後續**執行的特性，直接捕獲當前錯誤的地方從而確定是何條件未通過以及對應的提示語，從而提高後續的定位速度。
這段**本身並沒有改變多少思考正規化，本身也依賴 area 1 中的邏輯判斷語句的編寫，優點是在條件判斷的下一步做了一點統合，不必再每乙個分支內重複地寫 return or toast。簡單而言，就是用 reject 盡可能代替了 else。
同時，因為 area 1 中的需要編寫判斷的原因，這裡也是耦合度較高的地方，從這方面講，是可以後續改進的地方。不過，需要掌握好平衡。
當然，後續公升級的方向也可以是像 element-ui 的 form 那樣，傳入物件，傳入自定義的驗證器等等，同時這裡又要考慮作用域(用於某些表單聯動時上下文中的變數獲取)等等問題。
總之，沒有完美的解決方案。事物的發展是螺旋式前進的，實事求是，根據不同的實際抽象出不同的核心需求，然後選擇才能總結出相應的最合理的解決辦法。
1. 徹底消除if else， 讓你的**看起來更優雅；
利用Page事件進行統一身份驗證
建立乙個名為basepage的類,繼承system.web.ui.page public class basepage system.web.ui.page void basepage load object sender,eventargs e 其他的後台頁面直接繼承basepage即可。如 pu...
promise的一些特點
resolve進入then,reject進入catch newpromise function resolve,reject then function res new promise function resolve,reject catch function res new promise fu...
利用partial class 進行快樂的效率開發
高效率地開發，不僅僅需要技術，還需要的是一些現實的技巧，相對.net framework 1.1中的c 來說，語言中提供的partial關鍵字，可以說是乙個偉大的創舉，在真實的業務開發中，很多時間會遇到各類不同的函式歸類整理的問題，儘管在vs.net ide中有偉大的ide標誌 regoin.end...