這篇要討論的這個概念，應該也不是我發明的新詞，叫 URL 與狀態的雙向綁定，字面意思來說，在刷新頁面或跳轉頁面時解析 URL 並對應更新組件的狀態，在組件狀態更新時同步更新 URL，為什麼要引入這種機制嘞？ ...
記錄一些最近寫前端的思考總結，也算是給自己的技術隨筆開個篇
在接觸以 React，Vue 為代表的工程化前端框架前，我還是一個拿著 jQuery 手擼特效和手寫 CSS 的切圖仔，搗鼓 Vue 時接觸到的一個非常核心的概念就叫做“雙向綁定”，這裡的雙向綁定指的是視圖（template）與狀態（state）的雙向綁定，狀態的變化直接觸發組件的渲染，不需要手寫控制和更新渲染的 js 函數了（沒錯這是我之前乾的事）
這篇要討論的這個概念，應該也不是我發明的新詞，叫 URL 與狀態的雙向綁定，字面意思來說，在刷新頁面或跳轉頁面時解析 URL 並對應更新組件的狀態，在組件狀態更新時同步更新 URL，為什麼要引入這種機制嘞？
比如我目前在做的一個項目是一個管理後臺，在一個非常典型的日誌查詢場景，可以選擇和調整很多查詢參數進行查詢，但是由此就引出了一個問題，如果按照目前 Vue 雙向綁定的寫法，變更查詢組件的狀態（選擇或輸入參數等）不會反映到 URL 上，這時如果我需要將一組查詢好的結果分享給同事，只能複製當前的頁面鏈接給他，讓他進入後再選擇和我一樣的查詢參數，可以看到有一部分沒有包含在 URL 中的信息其實是被丟棄掉了，另外在進行站內跳轉時也無法跳轉的更“具體”，只能跳轉到 router 定義的頁面在初始渲染完成後的樣子
這就引入URL與狀態雙向綁定的好處了，比如我在日誌查詢頁面中選擇查詢方法為 POST ，等級為 ERROR 的日誌，監聽組件對應的狀態變更，並更新URL（假設為?method=POST&level=ERROR），同理適用於其他的變更
當然做到監聽組件狀態更新 URL 只是做到了雙向綁定的一向，要想讓你的同事真的恢復到你當前頁面的狀態還需要實現另一向的操作，即將 URL 解析到組件狀態，往往是在頁面組件 mount 時解析當前的 URL 路徑與QueryString，將其中的參數解析出來並與組件的狀態進行同步，事實上就實現了
URL ⇔ 組件狀態 ⇔ 組件視圖
帶給用戶的直觀體驗就是視圖與 URL 的綁定，這時如果你將瀏覽器中的鏈接粘貼給同事，他在打開時就可以復現你當前的組件狀態，進而得到你目前的視圖界面了
總結一下，實現 URL 與狀態的雙向綁定其實就是需要實現
-
監聽組件狀態更新URL（通過 watch 或 $emit 等手段）
-
將 URL 解析到組件狀態（如在組件 mount 時將 URL 參數解析並賦值給組件的 data 狀態）
帶來的好處有
-
分享鏈接可以讓訪問者完整復現當前頁面的狀態（至少是復現到你希望的粒度）
-
站內跳轉可以隨心所欲跳轉到任何可能的狀態（而且僅通過 URL 這種 Web 原生的方式，而非使用 Vuex 之類的狀態管理）
這樣的功能業界其實也已經有過一些開源庫能夠自動實現組件狀態與 URL 查詢參數的綁定，奈何自動化的方案給出的 URL 都太過冗餘，而我在命名方面又是一個強迫症，秉承著奧卡姆剃刀原則，我還是手動實現了每個狀態的綁定與解析，雖然較為機械化，但是往往就是在這種時候，我可以聽著音樂哼著歌，以近乎肌肉記憶的狀態有節律地敲打鍵盤，把這些不需要思考的代碼寫好
比起調 infra 里那些搖擺不定，反覆橫跳，此起彼伏的 bug，寫前端，調界面逐漸變成了一件放鬆身心的事~
寫於 22 年 4 月
