SPA項目經驗總結

最近選用了 React + React-Router 的技術棧，天然而然走了 SPA 的路線，下面總結下在所謂的 SPA 下的一些技術點的坑。

登陸態的維持

1. 現有方案
   登陸頁面發起 Ajax 請求得到用戶 token，把 token 存放在 localStorage 裏面，而後經過前端路由跳轉到用戶主頁。隨後用戶相關的請求都會在 http head 裏面帶上這個 token。服務器端只負責驗證每次請求中 token 的合法性（譬如：是否過時）。

2. 遇到的問題
   把 token 保存在 localStorage 中主要考慮用戶打開瀏覽器多個 tab 頁能夠維持登錄態。可是存儲在 localStorage 裏面的 token 面臨以下問題：

   • 被串改的風險比較大，一旦被篡改，能夠跨用戶操做。

   • 多帳號登陸相互覆蓋 localStorage 中 token 的問題。

3. 解決方案
   針對多帳號登陸相互覆蓋的問題，現有采起的方案是在登陸後分別在內存和 localStorage 裏面保存一份 token，每次要用到 token 的時候都去對比一下，若是檢測到不同則提示用戶關閉當前窗口防止串號。這麼作的目的一來防止用戶本身被多個帳號誤導，二來若是關閉了檢測到串號的窗口，不影響後登陸的那個帳號使用（固然若是前一個窗口不關閉也沒有問題，js 使用的始終是內存中的 token）。<br/>

可是當同一個用戶開多個窗口，那麼新開的窗口中的 token 第一次獲取就只能從 localStorage 裏面獲取。這時就有 token 被篡改能夠跨用戶操做的風險。針對這個風險我預想了解決方案（須要用到 session 存儲 token）：

1. 在已經登陸一個帳號的狀況下，不容許開新瀏覽器窗口進行其餘帳戶的登陸，即若是檢測到當前已是登陸態則不容許用戶停留在登陸頁。
![singleuser](https://cloud.githubusercontent.com/assets/631198/20826318/fbc8f078-b8a4-11e6-9401-ede5ff1294b1.png)
2. 在已經登陸一個帳號的狀況下，容許開新瀏覽器窗口進行其餘帳戶的登陸。
![multiuserlogin](https://cloud.githubusercontent.com/assets/631198/20826352/3971b34c-b8a5-11e6-9082-47515404346d.png)

    這種狀況下若是登陸了第二個帳戶，第一個窗口（第一個帳號）要再進行任何操做，傳回的 token 就和 server session 中的 token 不匹配，server 就能夠返回狀態碼讓前端把用戶登出。

多路由模塊共享數據同步問題

若是多路由之間有相關的業務數據，那麼爲了減小請求，提升用戶體驗，最好把多路由相關的數據共同抽象到一個地方，譬如 redux 的 store 裏面。這樣一個路由改了數據，當切換到另外一個路由就不須要從後臺再拉一遍數據的最新狀態。這點對於單人開發沒有問題，可是對於多人協做就須要提早設計數據存放結構，約定接口。一邊作一邊改就容易出現溝通問題，數據架構也不容易統一。

異步任務的狀態問題

針對有異步任務的狀況就要考慮狀態更新的問題。由於頁面提交了一個請求修改數據，可是數據被修改的最新狀態沒法當即體如今當前界面上，那麼就會有以下問題：

1. 頁面如何處理中間態即處理中的狀態提示。

2. 頁面是否須要接入服務器推送，等異步任務完成後把結果推送到頁面來更新狀態。

3. 異步任務尚未完成，用戶刷新了頁面並又提交了相同的任務如何處理。

問題1若是中間態存儲在前端，一旦用戶刷新頁面或者新開頁面就轉換成問題3了，因此後臺必定要作好驗證，前端沒法嚴格維持狀態。還有一種狀況就是後端存儲中間態，那麼不管是刷新仍是新開頁面用戶都可以看到中間態也會避免提交重複請求，可是這種方案就增長了後端的複雜度，須要根據項目的需求自行決定。

問題2涉及兩個方面：一來是接入推送服務增長複雜度的問題，須要酌情考慮。二來是提升用戶體驗的問題若是最新的狀態須要及時通知到用戶，那麼推送方案就要在技術選型時考慮在內。

多人操做同份數據

這個問題最典型的就是項目管理工具，針對同一個任務兩我的同時開着界面，若是一我的認領了，那麼另外一我的通常狀況下是沒法知道的，可能會形成「誤操做」。這個時候增長推送功能能極大的提升用戶體驗。