一 前言
關於用戶登陸，注冊，頁面跳轉，我講了很多，都是頁面框架級別的。有人問到這個問題，索性總結一下，今天是收尾最后一篇。
以往初學時的設計是：
1 注冊
2 登陸
3 進入頁面。
這種很簡單，沒有id就進不了主頁面。
但是實際上，除了通訊類的軟件，一般軟件不是先進入登陸頁面，而是先進入主頁，當操作某個功能時，再提示登陸。或者登陸后，在某個時刻更換帳號，重新進入登陸頁面。
像這種后來進入登陸頁后，用戶登陸成功后如何保證再回到web時，各個頁面的用戶id唯一性呢？？
用戶id更換，web中的每一個頁面必須同時更換。
也就是說，每個頁面的首要任務是：隨時接收用戶id,並判斷用戶id是否更改，如有更換，則即時更新用戶信息和權限。
登陸頁作為一個任意頁面的公共目標頁面，如何跳轉到來源頁面並正確傳參呢？
帶着這些問題，我們完成頁面框架的收尾工作。
二 效果演示：
1 進入主頁后登陸
2 更換帳號
如果用戶已經登陸，則彈出更換帳號對話框
用戶更換成功，頭像和號碼同步進行了更新
三 設計思路：
頁面同步，modeload可以不要，它只能初始化頁面，刷新一次data.但是modelParamsReceive異常重要，在頁面加載之前，監聽參數狀態，並進行參數接收，觸發data刷新。這個我在頁面同步的博文中簡單提過，現在深入一下。
四 頁面邏輯與代碼實現
1 監聽參數並接參，所有頁面都作如此處理，來保證用戶id是否更換，如有更接，即時過濾並得到當前行。data自動加載關閉掉，設置過濾條件后，接管刷新事件，效能問題影響不大。setFilter里的語句為ksql拼接寫法，其實是通過XHR的雙向聯接，用sql語句過濾數據庫，這就是說，每一個頁面，都用這種方法，保證用戶id一致性，效能不會有太大影響。
2 帳號更換
登陸與帳號的顯示切換，很簡單，一個三目表達式
未登陸與登陸后的頭像更換，同上
提示帳號更換的窗口彈出，用innerHTML得到span元素的值來判斷
justep.shell.showPage頁面跳轉並傳參，比以往多了一個from，這是一個鍵，我的定義是，哪個頁面跳轉到登陸頁，給它一個來源，登陸頁根據from，登陸成功后再回到
mine頁面。如果是其它頁面，則跳轉到其它頁面。不能每次登陸后去一個頁面，就要這么來設置。
3 登陸頁面
參數接收，不看不知道，一看，多了這么多判斷。登陸頁作為一個公共頁面，哪個頁面都能傳參回來，不能直接刷新data，根據來源頁面的this.params.from的值,得到來源是哪個頁面，才能決定，如何動作。
登陸成功后，跳轉到來源頁面。這里用變量，呵呵，這么寫還真行。
每個頁面都要接參並傳參，作為用戶id一致性的必要判斷。
4 所有頁面接參，再次重申
5 用戶id在傳參判斷中居首要地位。比如下圖中，一個頁面，左右兩個頁面都對它傳參，這個頁面就要首先判斷用戶id,然后根據來源執行不同的動作。
沒想到，后期登陸，帶了如此復雜的傳參問題。
我發現，有的同學中modeload里強制刷data,還有的是在modelactive時接參，這都是不對的。
經過反復測試，我拋棄了window.xxxx的全局變量，而是使用了邏輯復雜的傳參與接參。原因是window.xxxx變量雖然可以全局，但是需要手動得到，不能觸發類似於modelParamsReceive那種類似於監聽器的事件來觸發data刷新。以前探討過的全局可觀察變量，反復測試，在不同的頁面跳轉過程中，不能向上級頁面傳遞可觀察屬性。
比如，mine頁面已經打開過，再跳轉回來就不行了。
跟那個modeload一樣，只能初始化一次頁面。除非你關掉web重新打開。
五 總結:
1 modelParamReceive,是一個實時的監控事件，無論頁面是否打開過，都可以接參
2 modelParamReceive看似代碼復雜，實際簡單，可以實現更復雜的頁面控制
3 傳參，不僅僅是頁面跳轉，在多級頁面中，還起到中間頁面，控制簡單流程的作用。
相關視頻制作完成，上傳優酷。教學app制作中。我是邯鄲戲曲開發，tel：15175073123,qq:1017945251
掃描二維碼，看高清教學視頻。